App Store Proposal

Originially, 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.

Table of Contents

Store Page Contents

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 some groups might want to eventually think about Steam), 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. Too 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.

To help you with this problem we have created a special icon builder for you. This is a script that takes a 1024x1024 image and produces the correct formats for all platforms (Windows, macOS, iOS, and Android). See the instructions below for how to us it.

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 optimizing 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.

Store Page 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. The icon should be a 1024x1024 image. If it has any transparency, you should include the background color that you specified in the icon builder to make it mobile legal.

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,
  • Rating: The official
  • 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]((https://developer.apple.com/app-store/product-page/). 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.

Pay close attention to the fold. What are you saying in the first 250 characters? While you should not explicitly mention where the fold starts and ends (we will determine that from the character count), you should make the text in that part stand out.

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 (2019) examples below, to see what we expect in terms of screenshots.

Examples

We have used this document for several years now, though we skipped over it in 2020 because of COVID issues. All of these examples have their strengths, but whenever possible we include examples where there is an actual store page (Apple or Google) to compare to. However, not everyone wants to pay the $100 a year every year to keep the app up, so this is not always possible.

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 three years now, we do have some 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.

Family Style

The breakout success Family Style was developed in this course in 2019, the last year that we had this document. Overall this is a solid document. Pay close attention to their use of the introductory paragraph (“above the fold”) in the description. In fact, take a look at their official app store page which uses exactly the same description! The only thing weird about this proposal is that they chose to use “marketing-style” screen shots. These screen shots are not taken from the game, but are instead a “mini-manual” showing how the game is played. However, this is perfectly acceptable. Not only did Apple allow this, they even featured this game on their front page.

Pig Life Crisis

Winner of Most Polished (Mobile) Game in the 2019 Showcase, Pig Life Crisis has a fairly strong store page proposal. The screen shots are more traditional, but they do overlay tutorial text to help the viewer understand what is going on in the image. Our only complaint with this document is the text “above the fold”. If you read this text, you will see that it is all about the game story, and does nothing to educate the player on how the game is played. This is a wasted opportunity.

Split

Winner of Most Polished (Mobile) Game in the Spring 2018 Showcase, Split is another great example of a store page. It is to the point, and does not contain any more than you need. Of all the examples, we particularly like their icon. It is very representative of the game, capturing 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.

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. With that said are not sure if we are a fan of the “review quote”. Avoid these unless you have a good reason.

Beam

Beam was the winner for Most Polished (Mobile) Game at the 2014 showcase. They also had a commercial release and you can compare this proposal to what they really have in the Google Play Store (the iOS version is no longer available). 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.

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 talked about a commercial release, they never did get around to having one.

Icon Builder

Students notoriously have difficulty with icons in this class. That is because an icon for an application is usually not a single file (Windows being the lone exception here). The application needs the icon at multiple resolutions depending on the devices involved. So the icons are actually a collection of PNG files. Even in the case of Windows, the .ico format is a proprietary format that is just a collection of PNG files.

Your icons are located in the following directories

  • Windows: The file icon1.ico in build-win10/PROJECT (where Project is your project name)
  • macOS: The directory build-apple/Resources/Mac.xcassets/AppIcon.appiconset
  • iOS: The directory build-apple/Resources/iOS.xcassets/AppIcon.appiconset
  • Android: The directory build-android/app/src/main/res

To simplify this process, we have provided the script iconify.py. This is a python script that takes a 1024x1024 image and generates all of the necessary icon files.

The Python script requires the PILLOW package. You should install it if it is not already installed. To run the script, put it in the same directory as your image and type

python iconify.py image.png

where image.png is the name of your image file. If your image file has any transparency at all, you should specify a background color as a second argument. This background color should be a web color hex string without the # tag (as this confuses python). So to add a yellow background, you would type

python iconify.py image.png ffff00

If you want the transparency to remain on desktop icons (where it is legal) you can add the -t flag. The -r flag will add rounded corners if your image is rectangular.

For an advanced example, the CUGL icon source is actually transparent. The final icons for CUGL are generated with the command

python iconify.py -r cugl.png ef3d31

When you run the icon builder, it will put the results in a folder called output. You can use the folders generated to replace the appropriate folders in the Windows, macOS, and iOS builds. The Android folders will need to be merged, not replaced.

Submission

Due: Sat, Apr 30 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.