How to gather player feedback from your Unity game using AWS
In this article I’ll show you how to let players email you feedback and bug reports directly from your Unity game, using Amazon Simple Notification Service (or SNS). I recently did something like this in my game, so I thought I’d share what I learned. I’ll assume you know the basics of Unity, and basically nothing about AWS.
🤔 (Note: this tutorial is about using the AWS .NET SDK to call SNS from Unity! Another way to do the same thing would be to write an AWS Lambda function that calls SNS, expose that function on the web using AWS API Gateway, and then have Unity make an HTTP request to it. Pros and cons are outside the scope of this article, but you have options!)
AWS (Amazon Web Services) provides various services for people making websites or online applications. There are a TON of AWS services that do all kinds of different things — usually each service is focused on one specific thing, but they can all interact with each other too. In general I have found AWS to be fast, reliable, cheap/free if you use it on a small scale, and anywhere from “confusing” to “absurdly confusing” to learn. This is going to be easy though! I’ll try and break it down for new users.
For our purposes, we only need one part of AWS: Simple Notification Service, or SNS. SNS lets you notify various recipients (i.e. you can send an email, text message, push notification, or just run some code) whenever some event (that you define) happens. That’s all it does! It exists solely to do that. In this article, you’ll create a topic with SNS and then have your Unity game publish messages to that topic containing player feedback. You’ll subscribe your email address to the topic, so that whenever a new message comes in, you’ll get an email.
💡 (By the way, I got this idea from Subnautica, one of my favorite games that really paved the way for early access. In Subnautica you actually got an achievement for submitting user feedback from inside the game!)
Let’s get started!
First off, you’ll need to make an AWS account, if you don’t already have one. Note that using SNS may incur some charges, but your first 1000 emails per month are free, so unless you’re getting a huge amount of player feedback you’re unlikely to pay anything.
Now, from the AWS Console, find the Services dropdown at the top left and go to Simple Notification Service (you can also just type “SNS” in the search field). When in the SNS dashboard, take note of your region at the top right of the screen. When you configure any AWS services, you typically have to specify which part of the world you want your resources to be hosted in. For instance, you could have one server in the USA and one in Europe so your users can connect to whichever one is closer.
For now, a little extra latency isn’t going to matter so just pick the region closest to you. In the future, if it looks like your SNS topics have disappeared, make sure you’re looking at the right region!
Make an SNS topic
Now that we’re in the SNS dashboard, click “Topics” in the menu on the left and click the button that says “Create topic”. Give it a name like “PlayerFeedback” and a “Display name” of your choice (the display name will also show up as the “sender” of the feedback email). You can leave everything else the same, but take a look at the “Access policy” settings. By default, only the topic owner (your AWS account) is allowed to publish messages to this topic. In the next section we’ll make it so your Unity game can publish messages to it as well.
Subscribe your email to your topic
After creating your topic, navigate to its details page and click “Create subscription”. On this page, the “topic ARN” should be the Amazon Resource Name of the topic you just created (it should be auto-filled, but if not then clicking in the field should give you a list to choose from). Pretty much every resource in AWS has an ARN, which is just Amazon’s internal identifier for that resource. It can act as an ID, but in some situations you can also use them sort of like paths with wildcards to identify groups of resources.
💡 Copy the topic ARN and paste it into a text file because we’ll need it again later!
Now, change the “Protocol” to “Email”, enter your email address in the “Endpoint” field, and create the subscription. You should get an email from AWS asking you to confirm the subscription. Confirm it, and you should be good to go!
You can test the subscription by going back to the topic’s details page and clicking the “Publish message” button. This will let you publish a message to that topic directly from the AWS console. You just need to enter a “Subject” and a “Message” which will be the subject/message of the email — leave everything else the same. Try that now and make sure you get an email.
Now let’s set permissions so our game can publish messages to our topic!
You already have an AWS user, your root user. That’s the one you signed up for AWS with and that you use to log in to the web console. This user has admin access to everything in your AWS account. In the past, you could have access keys attached to this user and use those keys to do AWS things from your code, but that’s really insecure because you’d be giving admin access to your code (and anyone who could find the keys)! Since we want to let our game have AWS access, and then distribute the game all over the place, this is definitely not an option.
Instead, we’ll use IAM, or Identity and Access Management. This is how AWS lets you manage user security and permissions. In a nutshell, we’ll create a new user that is allowed to publish messages to our SNS topic (and nothing else), and then let our game use AWS with that user account.
This was confusing to me at first, so I’ll try and clarify the main IAM concepts as I understand them.
IAM User: This is a “user” that you can create inside your AWS account, and then give that user access to some of your resources via IAM Policies. That’s what we’ll be doing in this tutorial.
IAM Policy: A policy is the basic unit of IAM security. It’s a little piece of text in JSON format that describes some security rules, like who can access which resources. A policy can contain a rule like ”allow user X to publish messages to SNS topic Y”. AWS has a bunch of default policies you can use in various situations, or you can write your own. By itself, a policy doesn’t do anything! Something needs to use the policy for it to have any effect. Sometimes Amazon uses the word “permissions” when they mean “policy”.
IAM Role: A role is another way to use IAM policies. You could grant a role to an IAM user temporarily, meaning it uses the role’s policies for as long as it has that role. Also, sometimes AWS services themselves want to access your resources — in that case you can tell the service to adopt a role that gives it the appropriate permissions. We won’t be using roles in this tutorial, but it’s good to know!
Create an IAM User
Now that we know what we’re doing, go to the AWS “Services” dropdown again, and this time find IAM. From the IAM menu, go to “Users” and then click “Add user”. Give the user a name like “feedback-sender”, select that you want it to have “Programmatic access”, and just click “Next” through all the remaining screens — we’ll attach a policy in a minute!
💡 On the final screen after creating your user, take note of both the Access key ID and the Secret access key. Copy them both to a text file somewhere — you won’t be able to get the secret key later (but you can always create new keys)!
Give our IAM user permissions to our topic
Now go back to the IAM users section. Click the user you just created, and in the “Permissions” tab you should see a link on the right that says “Add inline policy”. An inline policy is one that’s attached to the user object itself, so it will be easy to find and manage. If we wanted to reuse the policy with multiple users we could create a full one, but for our purposes an inline one is less clutter.
Create an inline policy that allows your user to use the SNS service to publish (it’s in the “Write” category, or just type it in) to one specific resource, which is your topic’s ARN (if you lost the ARN from earlier, you can find it in the SNS dashboard). When you’re done, it should look like the below image.
If you check out the JSON tab, you can see the policy that will be created. It should look something like this:
Finally, click “Review policy” and give it a name like “feedback-user-publish-to-sns”. After you’re done, your inline policy will appear under the IAM user and you’ll now be able to publish messages from Unity using that user’s keys.
⚠️Make sure you never give this user any more permissions! Malicious players could scrape your keys out of your game build and use them.
🤔 Remember the “access policy” settings back from when we created the SNS topic? Another way to do this would have been to edit the topic’s access policy to give our user permissions to the topic.
Make some feedback UI in our game
That’s it for the AWS side of things! Now we need to make some UI that lets the user type in some feedback. Like I said above, I’m assuming you know the basics of Unity, so I won’t go into much detail here. I just made a simple panel with a text field, an error label we can show if anything goes wrong, and some buttons. I can show the feedback form in-game by setting its game object to be active, and then it sits on top until the player sends or cancels.
Add the AWS SDK to Unity
Okay, now we need to write code in our game to let users send feedback. To help with this, Amazon provides a .NET SDK that lets us work with AWS. The AWS SDK is split into pieces depending on which AWS services you want to use.
Getting the SDK into Unity is a little bit of a pain. There is a Unity build of the AWS SDK, but as of now it’s using legacy .NET 3.5 and we won’t be able to use nice async tasks, so let’s avoid that.
Instead, for each AWS service you want to use, you’ll need to do the following:
- Download the package from NuGet
- Rename the file to have a .zip extension
- Unzip it
- Find the .dll in the lib/netstandard2.0 folder
- Copy/paste the .dll to somewhere in your Unity Assets folder
Let’s hook it up!
Hopefully you survived the above and now we’re ready to write some code. Here’s an example MonoBehaviour you can add to your feedback form (this uses TextMeshPro which is bundled with Unity, but you could easily edit it for whatever you’re using):
To use this, do the following:
- Add it as a component to your feedback UI’s GameObject in the Unity inspector
- Wire up your input text field, error message label, and send/cancel buttons to the corresponding fields in the component
- Fill out your SNS details (you can find your region code in your SNS topic ARN)
- In the Unity inspector, have your buttons’ OnClick() handlers point to FeedbackUI’s OnClickSend() and OnClickCancel() methods
- When you want to show the form, just do something like
feedbackUI.gameObject.SetActive(true).In my game, I have a small button at the bottom right of the screen that players can click at any time.
And we’re done! I tried to comment the code well, so hopefully it should all make sense to you. If all went well, your players can now send you feedback and bug reports directly from your game to your email.