Assignment 15
App Store Proposal

Due: Saturday, April 27th at 11:59 pm

Historically, the final formal document for this class was the game manual (just as it was in the introductory course). However, game manuals are even less appropriate for mobile games. The entire purchasing process is digital, and there is no box to bundle a manual with. Furthermore, the shortened play times of these types of games made a manual more of a burden than an asset. Therefore, many students requested that we replace the manual with something more modern and relevant.

The obvious choice to replace the game manual is an app store page. This is all a potential player will ever seen before purchasing your app, and it is where you would put many of the things that you previously put in a manual. Even if you are making a PC game, Steam pages are very similar those on an app store.

Unfortunately, app store page formats vary quite a bit between platform. Therefore, we have come up with a compromise that we think will be relevant for everyone. Below, we describe the important features of an app store page. We then explain how we want you to take those features and put them in a single PDF that is easy for us to read and grade. Finally, we have provided several examples for you to look at.

Creating an App Store Page

We are basing this exercise off of the instructions for creating a page on the iOS App store. The Google process is very similar. Even though Some of you are Android developers (and at least one group is really a Steam developer), we prefer to focus on the Apple style because it is more limited. For example, Apple does not allow you to put HTML tags in your descriptions, while other stores do. Therefore, if you know how to make a page for the iOS app store, then you can make one for any platform.

If you read the link above, you will see that creating an app store page consists of submitting multiple files. Most of these files are either XML files or Property Lists (which is an Apple-specific type of XML file), that fill in important information for several predefined properties. These include things like the seller name, the game name, the game price, ratings for age restrictions, and so on. The platform (in this case, the iOS app store) uses these XML files to autogenerate the web page for your game. This ensures that all apps in the store have a uniform look.

These XML files contain all of the textual information for your store page, including the app description. However, they do not include the images for either your icon or screenshot. Those must uploaded separately, and they must adhere to specific guidelines set out by the app store. You cannot have any images other than your icon or screenshots.

Because your app store page is autogenerated, it often seems like it is hard to get your app to stand out. As a result, there are lots of guides online for how to optimize your description for more traffic. Whatever you do, there are four main things that matter.

Title and Icon

The title and icon are often the only thing that a potential player sees when scrolling through a list of games. Most of your have already settled on your game title, and there are no clear guidelines for how to title a game (on the other hand, there are a lot of rules for how to come up with a name for a productivity app). So that leaves the icon.

Your icon is the single most important piece of artwork that you will create for your game. It is what appears in the app store when your game is listed. It is what appears on the home screen of a phone or tablet. It needs to convey some important feature of your game, such as the main character, the art style, or the basic gameplay. It should look great at 512x512 resolution on your app page, but it should also be recognizable as a 57x57 thumbnail on any of the various app store lists.

Apple has a very important rule about icons that you should be aware of: no alpha channels allowed. To many people were using transparency in their icons in ways that were deceptive, so Apple outlawed it. You might ask "but how do I get rounded corners?" They answer is that Apple cuts off and rounds your corners after you submit the icon. So the submitted icon must not have any transparency.

For this class, we will compromise. You can round the corners yourself, but no other transparency is allowed. If you do not understand how corners are rounded, look at this template.

Description

The description is a plain text description of your game and its features. It is a lot like your concept document, except that it is written for players instead of a producer. App store descriptions often start with a high concept pitch, and then include descriptions of features and design goals. They also often include quotes from reviews, if you have been doing a lot of outside marketing to review sites.

Apple keeps its descriptions in plain text because too many submitters had abused formatting features such as bolding and special characters (see the examples at the end of the article for optimize your description). Apple decided that they only wanted section breaks to occur at places defined by the metadata, so they eliminated all formatting and all special characters.

However, you still want to break your description into sections, even if that means using low-tech ASCII art. Modern app store pages often use all caps in place of bold, and underscores or equality symbols (=) to indicate section breaks. The app store page for Monument Valley is an excellent example of this type of formatting.

The key thing to understand about the description is the character limit. You are limited to no more than 4000 ASCII characters. This includes all white space (such as blank lines) and section formatting. In addition, only 255 characters are displayed above the fold. By default, the potential player only sees the beginning of your description, which ends at a place called the fold; the player must click on "more" to read the rest. Just like the concept document, your most important information needs to go at the beginning.

Keywords

Apple does not support sophisticated search algorithms in its store. You get to choose the keywords that will match your game. They have to be exact matches; misspelled keywords will not match your game (which is why many shady apps include misspelt keywords). You can provide as many keywords as you want, but they are limited to 100 characters, including the spaces between keywords.

Keywords are a topic for which you can get a lot of advice online. It is not that much different from search engine optimization. In addition, there is a helpful site call Sensor Tower. This web application allows you to reverse-lookup the search keywords for all of your favorite apps. That is how we found the keywords for the Monument Valley example below.

Screenshots

The last important feature are your screenshots. They need to be self-contained, since they are uploaded without captions. Furthermore, they need to be actual screenshots from your game (though they could include a title screen or tutorial) and not include any additional annotation. If you are targeting multiple devices (e.g. both smartphone and tablet) you need to upload screenshots for each device type. This is particularly important if your UI is different on different devices.

Creating a Store Proposal

As you can see from the iOS App store instructions, creating an app store page involves a lot of files. We do not want you uploading a lot of files to CMS. Instead, we want a simple PDF, just as you have submitted for all of the other assignments.

In addition, we would like to understand your reasoning for the various choices in your app store page. Why did you design your icon the way you did? Why did you choose those keywords? What are you trying to highlight in your screenshots? For this reason, we want you to submit an app store proposal. This is a PDF that will contain all of the important elements (mentioned above) of your app store page, together with a short justification.

As with all documents in this class, the exact format of the document is up to you. However, your document needs to include the following information.

Icon

You need to design an icon and include it in the PDF. The icon should be accompanied by a paragraph (or two) describing the important elements of your icon and why you think it will be effective. As we said above, you are allowed to round your icon, but no other transparency is allowed.

Store Information

This section should include a table with (what we consider to be) the most important metadata for the store page. In particular, we are looking for

• Seller: Your studio name
• Version: The current version number of your game
• Category: Your app category, which should be Games
• Subcategory: The category indicating your type of game
• Price Tier: The amount to charge for your game, consistent across multiple currencies
• Rating: The official age restriction for your game
• Size: The amount of storage space required for your game
• Compatibility: The exact devices and OS versions required to run your game
• Keywords: The search keywords for your game (100 characters or less)

Your proposal must include all of the information above. You are also free to include any other properties outlined in the iOS App store instructions. For example, if you have an external website to market your game, you can include that. If you support languages other than English, you should also include that.

In our experience, the two trickiest issues are the keywords and the age rating. After the table, you should include a short subsection justifying your keywords. You should explain why you chose the keywords that you did, and why you think they will be effective.

As for the rating, please use the Apple age rating categories which is not the same as ESRB. There is no E for Everyone. Apple breaks things down into much finer age groups. Most of what you think of as E for Everyone is actually ages 9+. If you have any violence at all, even Bugs Bunny fantasy violence, you are ages 9+.

Description

This section should include the description of your game. You are allowed to recycle features like the high concept statement or design goals from other documents. The challenge in this section is to stay in the character limit and format it appropriately. We will also be looking at the information above the fold to make sure that it is punchy enough (you do not need to indicate the fold; we will determine that on our own).

Because ASCII formatting is such an important part of this section, you should use a monospaced font like Courier, Courier New, Lucida Console, or similar. You should all caps for section headers and underscores or equality symbols for section breaks. If you want a bulleted list, use asterisks (*) for your bullets.

Screenshots

You should include 4-5 screenshots to show off your game. The screenshots should not be captioned, but you should include a paragraph explaining why you chose the screenshots that you did. If you are targeting multiple devices (e.g. both smartphone and tablet), then you should have a separate screenshots section for each device.

To use screenshots effectively, they do not need to be a perfect picture of the screen. You are allowed to add extra elements like fingers or tutorial text to put the pictures in context. Look at the more recent (2018) examples below, to see what we expect in terms of screenshots.

Examples

We introduced this assignment for the first time two years ago. Therefore our examples are limited. However, the students really liked this assignment, and though that it was a lot more useful than the manual assignment. So we have made it permanent.

Monument Valley

To get this assignment off the ground, we created a fake store proposal for Monument Valley. This proposal used information taken directly from their store page (the one they had at launch, not the current one), but reformatted to match the format outlined above. In addition, we have added several commentary paragraphs to show what justification should look like.

The description for Monument Valley is very enlightening, and is one of the reasons we chose this game. You will notice that it has three clear sections: a high concept statement, a list of review quotes, and a list of design goals. The high concept statement and design goals are exactly like the things you have written before in class. Reviews are new, but none of you have reviews, and I do not want you to add fake reviews.

Because we took this document straight from their store page, there are several issues in the description that violate the Writing Guidelines. Not all of the subsections are in all caps. The section headers also mix word cases; some headers are adjectives while others are nouns. The makers of Monument Valley did not get a grade on this, so they are okay. However, you are getting a grade, and so we will hold you to the Writing Guidelines even when it is just ASCII formatting.

CS 4152 Examples

Because we used this assignment for two years now, we do have several other examples to look at. Some of these examples are really instructive, because the games were later released in an actual mobile app store. That means you can compare the proposal to the actual release.

Split

Winner of Most Polished (Mobile) Game in the Spring 2018 Showcase, Split is a great example of a store page. It is too the point, and does not contain any more than you need. Their icon is also an excellent example of the game, capture the mirror dynamics in its visuals.

Discarded

One of the more ambitious the mobile games at the Spring 2018 Showcase, Discarded can be a daunting game for a newcomer. It has an usual backstory and complicated mechanics. They have done an excellent job with the screenshots conveying how the game is supposed to be played.

Inari

Winner of Most Polished (Mobile) Game in the Spring 2016 Showcase, Inari is almost exactly what we are looking for in an app store page. The description is short and to the point, and they cover all of the important issues. However, they have the old-style screen shots, and so they do not put their images in context.

Laser Penguins

Winner of the Audience Award (Mobile) in the Spring 2017 Showcase, Laser Penguins is a multiplayer "marble" shooter, which uses the accelerometer to move your penguins about on ice. Because their control schemes are so unusual, they use the screen shots to show off tutorial information. This gives the user a much better understanding of how the game plays, and whether to download it.

Underhand

We have talked about the 2017 viral sensation Underhand all semester long. The app store proposal is solid. However, the real stand out feature is the icon design. See how simple the icon is, but how it conveys everything that you need to know about the game. You can tell both the gameplay (cards) and the art style (hyper-stylized Art Deco) from this single icon.

Squeak & Swipe

Winner of Most Innovative (Mobile) Game in the Spring 2016 Showcase, Squeak & Swipe also has a very simple and straight-forward app page. We are not sure if we are a fan of the "review quote", however. Avoid these unless you have a good reason.

Beam

Beam was the winner for Most Polished Game in the mobile division at the 2014 showcase. They also had a commercial release and you can compare this proposal to what they really have in both the Google Play Store and iOS App Store (currently unavailable). However, this document has a problem in that they use monotype font for both their description and their explanations. Do not do this. Only use monotype for the description.

Project Apollo

The puzzle game Project Apollo was the winner for Most Polished Game in the mobile division at the 2015 showcase. It was not a strong as Beam, but it was also released in the iOS App Store. However, the screenshots do not have any description associated with them. We want at least a paragraph describing why you chose the screenshots that you did.

Over the Arctic Hills

We have used Over the Arctic Hills all semester as an example of good documentation. Once again, they did a really solid job on this assignment. Why they are talking about a commercial release, they have not had one yet.

Flick Ship Spaceship

The flicking game Flick Ship Spaceship was an audience favorite in the mobile division at the 2014 Showcase. They later released this game for free on the Apple store, but it appears that it has been take down (one of the creators went to work for Apple, and they might have required this). Unfortunately, I did not screenshot the Apple store page.

Stack N' Smash

The multiplayer game Stack N' Smash has a very simple app store proposal, but it is everything that we are looking for. However, we had to show it off because of the icon. This is the best game icon anyone has ever made for this course. Notice how it clearly illustrates the action in this game.

Submission

Due: Saturday, April 27th at 11:59 pm

You should submit a PDF file called storepage.pdf representing your proposal. As usual, we ask that the file be a PDF so that we can annotate it in order to return it to you with feedback for possible revision. More importantly, we are expecting some art assets in this proposal, so you will need to use PDF for that reason as well.

As with every other document in this course, this is not the final draft of your proposal. You will get another chance to revise this propoals for final document portfolio. However, because we are so close to that assignment, there is no chance for intermediate revisions before then. Therefore, this assignment is different from the rest. For the store page proposal, "final" document portfolio is actually just another draft. The final, final version of your store page proposal is to be submitted at Showcase.