游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

应用开发者不应忽视文件大小的问题

发布时间:2013-11-01 16:44:28 Tags:,,,,

作者:Tobiah Marks

当你在执行应用时,请密切关注文件的大小。

当你将代码,图像,声音,视频和其它资产编辑在一起的时候,你的应用有可能会变得非常大。我便看过从250MB到2GB范围内的许多游戏。有些游戏需要更大的规模,但许多游戏在较小规格下也能够出现同样的效果,前提是你需要为此付出额外的努力。

有时候游戏在发行时的规格并不大,但是基于“应用是一种服务”的业务模式使得内容会随着时间而不断变大,文件大小亦是如此。

为什么这点这么重要?

文件大小之所以制约着应用的成功主要有几大原因。

下载

不管怎样,如果你的文件偏大,你便等于强加给用户他们可能不愿意或不能够克服的需求。

用户将判断你的应用的价值,并只会在它比额外的“准入代价”需求还出色的时候下载游戏。首先他们必须使用WiFi。其次,他们的设备必须具有足够的空间。做到第二点比第一点困难,而这完全是基于你的应用的大小。

不管出于什么原因,让我们假设他们此刻不能下载你的应用。你总是希望用户一开始便非常喜欢应用并想要拥有它,那么额外的“代价”便会导致他们放弃购买念头。即使他们决定“之后再购买”,但是依照人类的本质,他们最终只会忘了它。不要让用户有之后再回来下载的想法。

再一次假设你创造了一个摩擦点并失去了潜在用户。或者更糟糕的,他们在购买应用前不会注意文件规模要求。而当他们在下载了应用后意识到自己不能使用该应用时,他们便会因为郁闷而在应用商店里给你的应用差评。即使他们并未真正使用过这一应用。

卸载应用

文件大小将影响着用户是否愿意下载你的应用,但阻止用户在之后卸载应用也同样重要。

当我耗尽手机容量时,我会做的第一件事便是检查基于大小排列的应用。如果你的应用是在这一列表上的最上方,它便最有可能被卸载掉。即使用户非常喜欢你的应用,如果他们需要足够的空间去存放更多mp3文件或新应用,他们便会选择放弃你的应用。如果你的应用属于小规模应用,基于3d下载标准,那么用户便很少会沿着应用列表往下拉去找到你的应用。

如果你的应用小于其它应用,那么即使其它应用的使用频率高于你的应用,它们被删掉的几率也会大于你的应用。如果你的应用是25MB而其它的是100MB,我会更愿意留下我有点喜欢的小应用而不是半常使用的100兆应用。

appfilesize(from gamasutra)

appfilesize(from gamasutra)

留下玩家的价值

如果你们拥有的是一款没有应用内部购买或广告收益的付费应用,那么积极安装才更重要。如果用户不将你的应用留在自己的手机上便会破坏你的业务发展。每一次的卸载都会让你失去更多潜能:

市场营销。用户经常会从好友或陌生人的体验/自己的手机上发现新应用。

推荐。如果用户时常使用某一应用或将其较长时间留在自己的手机上,他们便更有可能去推荐该应用。

排名。主动安装是影响应用商店排名的关键元素。同时,长期用户更有可能积极评价应用,从而帮助它提升排名。

未来收益。如果你在某一天添加IAP会怎样?如果用户不再使用你的应用,你的新内容不再有潜在用户的话会怎样?

未来应用的成功。比起旧应用,向现有的用户基础宣传一款新应用更加简单。

文件大小应该是怎样的?

对于手机平台,我会建议你尽最大努力基于手机下载限制去调整应用。

基于用户的设备,计划以及他们下载应用的商店等等,这一范围可以在20兆到50兆之间。这听起来可能不多,但我想提醒你的是,也有许多带有持续内容的复杂应用的规模低于50兆。除非你的应用拥有较多资产和较长的游戏时间,否则用户便不可能忍受较大的文件规模。

的确有一些游戏类型避免呈现较大的文件。如果你拥有的是一款付费游戏(特别是当它的定价高于3美元)或是带有现实3d图像而瞄准硬核玩家的游戏,那么用户通常都会愿意原谅你的大规模文件。

我该如何缩小文件?

48兆与75兆间的差别在于几千的下载量(或卸载比例)。在发行前你应该再次着眼于自己的应用。你是否能够缩小文件规模?你需要在发行前投入额外的时间和努力去缩小文件规模。以下是帮助你做到这点的一些方法。

牢记文件大小去设计资产

当你在设计应用的元素时,你必须清楚什么需要一个独特的资产,什么能够在运行过程中创造出来,什么没有必要存在。

当然,想象中的菜单界限在理念的绘制过程中可能会看起来很酷,但实际上可能只是一个简单的斜边,并占据着较少的纹理文件?

可重复的小型纹理可以取代更大的背景图像文件。当你拥有一个大型资产时,你可以问自己是否可以将其分解成一些较小的元素?如果可以的话,也许你应该使用重复的纹理。

如果你的游戏拥有一个关于草原,山以及其中一座山上的小房子的巨大图像,你可以尝试着为每个元素创造一个可重复的纹理。草,山以及关于房子的一个小图像。如果你能够将图像分解成一些较小的组件,然后基于代码去组建它们,你便可以无需使用任何大型资产文件而让它们看起来像是带有更多细节的背景。

你甚至可以在创造新领域时循环元素。举个例子来说吧,沙漠可以使用与草原一样的山纹理。如此你不仅可以使用较少的文件空间,同时你也可以更快且更便宜地创造新内容!

动态地生成资产

突出或区分一个重要的按键很重要。但是否表示每种按键都需要独有的图像?

你是否能够设置一个灰色的“模版”按键并在代码中为其改色以区分开来?

游戏的背景音乐需要占据巨大的磁盘空间。然而你并不希望同样30秒的循环不断重复着,这会让玩家疯掉的。尝试着为你的音乐分层。设置30秒到60秒的“基本”循环(如鼓),然后再随机基于15至90秒的分层(如吉他/萨克斯或其它旋律)。

基于这种方法,玩家每次游戏时都将听到随机生成的“歌曲”。这也许拥有重复元素,但是其独特方法却足以提升玩家的兴趣并让他们认为音乐歌曲比实际上还长。

在适当的地方使用精灵列表

精灵列表是关于将精灵几何(也就是图像资产)集中在一个更大的图像上。

为什么这一方法有效?这里存在几个原因,但是从我们的讨论目的来看的话主要是因为二的次方。

计算机是二进制的,文件储存是完全基于二的次方。如16, 32, 64, 128, 256, 512, 1024等等。如果一张图像大于二的次方,它便算用尽了下一个二次方在内存中的同样空间数。

尝试着着眼于一个图像属性,你将看到两个值。“大小”和“磁盘大小”。130×300的图像用掉了与256×512图像一样大的内存。如果你将图像资产与大型精灵列表结合在一起,你便有可能节省下所有磁盘空间。单独看一个512×512或1024×1024的精灵列表很大,但从潜在上看却比其每部分的组合小很多。

基于该方法你需要投入更多经历。你必须编写一些额外的代码去渲染精灵列表,面向每个资产/纹理只使用适当的图像区域。奖励并不会只是以文件大小而结束。如果你做得合理的话,这将能够节省下不少空间去渲染场景,从而让你的游戏拥有更好的表现。

压缩资产

使用压缩格式最有意义。

JPG非常适合大规模压缩,尽管它们落得了人造物的坏名声。PNG非常适合精灵,它们允许呈现出透明效果,但你必须注释是使用PNG-8还是PNG-24。PNG-8允许最多256种不同的颜色,而PNG-24则支持最多1600万种颜色。

问题在于,你是否需要全部1600万种颜色,或者你能否只使用256种颜色而创造出好看的资产?使用PNG-24并没有错(或者PNG-32),只是你必须确保在压缩版本有效的时候不会去使用它们。

同时还记得要粉碎它们。

删除垃圾代码

似乎每个广告商都希望你能够整合他们的SDK。

他们会宣称“在五分钟内完成设置!”这并没错,但通常情况下你不会在他们的平台上使用他们提供的全部功能。根据我的经验,你最终只会使用他们框架的一个元素。

考虑使用广告调节去减少你需要输入的SDK数量。

花时间去浏览他们的SDK并观察自己真正需要的内容。是否能够简化某些内容?如果你不使用它们的话是否能够删除整体的文件和资产?有时候,一些框架所包含的全部SDK都是你不会用到的,那么你能否完全删除他们并继续有效运行你的应用?

从网页上下载新资产

我喜欢将这称为“作弊”!

有时候我已经下载了一款25兆以下的游戏,而当我在每个新领域打开它时,它总是会想下载“额外内容”。突然之间我的设备上便会多出一款100多兆的游戏!

不过不要误会,我所说的作弊并不是坏事。至少这并不是一个糟糕的理念。它允许玩家进行下载并基于较小的下载内容做某事,之后如果你不能忍受缺少额外资产的话,便可以让玩家在千万新领域前下载这些额外内容。

如果玩家并未打开或不想访问丛林世界,那就不要下载这些资产便可以。这让玩家能够更快速地前进,而应用规模是基于他们真正使用的内容而不是他们可以到达的每个潜在区域。

然而这里还存在一个主要问题。它要求一个内部链接去打开新内容。如果玩家并不想用掉自己的3g宽带流量,或者不能访问WiFi的话,这便会招致可怕的玩家体验。当玩家被迫下载一些自己不想要的内容时,他们便会以“缺少内容”给予游戏差评。

我只会在这是作为可选择游戏内容,或者你的游戏要求内部连接(就像多人游戏,或只在应用内部购买时下载)时建议这种方法。

删除临时文件

如果你的应用曾经生成或下载过文件(游戏邦注:储存游戏,内部图像/截图,额外的数据等等),那就继续追踪它们。可能你的用户将永远都不会注意或在意这些内容,直到有一天你的应用激增到一个巨大的规模,并被列入了卸载的行列中。

留心哪些文件是必要的,而哪些即使删掉也没关系。设置代码去清除临时文件,即使应用在玩家上一次使用时突然崩溃或终止。

在测试期间你可能会反复安装,卸载再安装应用,但是用户将在每部设备上只安装一次你的应用。你肯定不希望自己的应用会随着时间的发展而膨胀。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

File Size, an important factor often overlooked

by Tobiah Marks

When making the executable for your app, pay close attention to your file size.

When you compile your code, images, sound, videos and other assets all together, your apps can easily become quite large. I’ve seen too many games that sit in the 250mb to 2gb range. Some games need that much, but many could be done very similarly with a smaller size, if they just put a little extra effort into it.

Sometimes the game wasn’t that large at release, but with the “Apps are a service” business model the content grew over time and the file size grew in equal proportion.

Why does this matter?

There are multiple reasons why file size is important for the success of your app.

Downloads

No matter what, if you have a large file size you’re imposing requirements the user may not be willing or able to overcome.

Users will judge the value of your app, and only download if it’s greater than the additional “cost to entry” requirement. First, they have to get access to WiFi. Second, they must have enough room on their device. The second could be harder to get than the first, depending on exactly how big your app is.

For whatever reason, let’s say they cannot download your app at the moment. If they liked your app enough to want it in the first place, that extra “cost” pushed them over the edge to decide to not buy it, losing a customer. Even if they decide to “get it later”, they’ll resume going about their day, and by the nature of people naturally they’re likely to forget about you. Never making the time to go back to the store later and download.

Again, you’ve created a friction point and lost potential customers. Or worse, and most likely, they won’t look at the file size requirement before purchasing. When they realize they aren’t able to use the app they just tried to download (possibly paid money for!), they might decide to rate you poorly on the store in frustration. Even if they haven’t actually used the app yet.

Uninstalls

It’s one thing to talk about file size in terms of being harmful to the struggle to get a user to download your app, but it’s equally important for preventing uninstalls afterwards.

When I run out of space on my phone, first thing I do is look at my apps sorted by size. If you’re app floats to the top of that list, you’re that much more likely to get uninstalled. Even if the user overall likes your app, if they need the space that may not enjoy your app enough over being able to fit more mp3 files or other new apps on their device. If you’re one of the smaller file sizes, at the 3g download level or under, the user has to scroll way down their list usually to reach your app.

Your competition, other apps that are larger than you, become much more appealing targets to uninstall first, even if they use them more often than yours. If you’re app is 25mb and theirs is 100mb, I would rather have one app I kinda like + 1-3 other apps or files I may enjoy than one 100mb app I use semi often.

Value of keeping users

Even if you’re a premium app with no in app purchases or ad revenue, active installs matter. Users who don’t keep your app on their phone will harm your business. With every uninstall, you’re losing potential:

Marketing. Users often find new apps by observing which ones their friends/strangers use or have installed on their devices.

Recommendations. Users are more likely to recommend an app to a friend if they use it/keep it on their phone constantly.

Ranking. Active installs probably plays a key factor in app store rankings. Also, long time users are more likely to positively review the app, which will also help your rank.

Future Revenue. What if you add IAP some day? If they no longer use your app, no longer a potential customer of new content.

Future Apps Success. It’s a lot easier to advertise a new app to an existing user base of an older app.

Just to name a few.

What should my file size be?

For mobile platforms, I would highly recommend you to make your best effort to fit your app under the cellular download limit.

Depending on the persons carrier, plan, and which store they’re downloading from, that could be anywhere from 20mb to 50mb. That may not sound like much, but I assure you, there are many complex apps with long-lasting meaningful content under 50mb. Unless your app is asset heavy and hours long, users aren’t very tolerant of large file size.

Yes, there are some kinds of games can get away with larger file sizes. If you’re a premium game (especially if you cost more than $3) and/or target core gamers with realistic 3d graphics, generally users will be more forgiving of larger file sizes. Only if it’s warranted.

How can I reduce file size?

The difference between 48mb and 75mbs can easily be thousands of installs (or uninstalls prevented). Take a second look at your app before shipping it. Can you reduce the file size? It could be worth the extra time and effort to decrease the size as much as possible before you ship. Here are some ideas to help reduce the size of your app.

Design your assets with file size in mind

When you design elements of your app, keep in mind what needs a unique asset, what could be generated on the fly, and what doesn’t need to be there at all.

Sure, that fancy menu border might look cool in the concept drawing, but would a simple beveled edge look almost as nice, and take up less texture files?

Small, repeatable textures can replace larger background image file. When you have a large asset, ask yourself, can you break it up into smaller elements? If so, perhaps you should use repeating textures instead.

If your game has a huge image of a grassy plain, mountains, and a one little house on one of the mountains. Try instead making a repeatable texture for each element. The grass, the mountains, and then a tiny image for the house. If you break up the image into smaller pieces, then assemble them in code, you can make them look like a larger more detailed background without using any large asset files.

You can even recycle elements when creating new areas. For example, the desert zone can use the same mountain textures as the grassy plains. Not only will you use less file space, but you’ll also be able to create new content faster and cheaper!

Generate assets dynamically

It makes sense an important button would be highlighted/look different from others. But does each kind of button need a unique image?

Could you have a grey “template” button and in the code recolor it to create differentiation instead?

Background music for games can also be a huge hog of disk space. Yet, you don’t want the same 30 second loop to repeat over and over and drive players crazy. Try layering your music. Have various 30 to 60 second “base” loops (Ex. base/drums) and then randomly layer on 15 to 90 second “tunes” (Ex. guitar/sax/whatever melody) on top.

That way, the player will hear a randomly generated “song” each time they play. It may have repeating elements, but the unique way it’s continuous streamed together will (hopefully) be good enough to keep the player’s interest and make them think the music tracks are longer than they actually are.

Use sprite sheets where applicable

A sprite sheet is a collection of sprites (aka, image assets) placed together into one larger image.

Why is this useful? A couple of reasons, but for our purposes, it’s because of powers of two.

Computers are binary, and file storage is all based on powers of two. 16, 32, 64, 128, 256, 512, 1024, etc. If an image is larger than a power of two, it uses up the same amount of space in memory as the next power of two.

Try looking at an images properties, you’ll see two values. “Size” and “Size on Disk”. An image that’s 130×300 uses up the same amount of memory/size on disk as a 256×512 image. If you take your image assets and combine them into large sprite sheet, you will likely save on overall disk space. One 512×512 or 1024×1024 sprite sheet is big by itself, but could potentially be much smaller than the sum of its parts.

This method does need more work on your part. You will have to write some extra code to render the sprite sheet, only using the appropriate region of the image for each asset/texture. The rewards don’t just end with file size however. When done correctly, this will also save on the number of draw calls being made to render the scene, giving you better performance as well.

Compress assets

Use the compression format that makes the most sense.

JPGs are great for heavy compression, although they are notorious for artifacting. PNGs are great for sprites, as they allow transparency, however make note if you’re using PNG-8 or PNG-24. PNG-8 allows for up to 256 different colors, and PNG-24 supports up to 16 million.

The question is, do you need all 16 million colors, or can you make your asset look nice using only 256? It isn’t wrong to use PNG-24 (or even PNG-32 if you need per pixel alpha transparency), just make sure you aren’t using them when a more compressed version would look just as nice.

Also, remember to crush them.

Remove junk code

It seems like every advertiser out there wants you to integrate their SDK.

“Get set up in five minutes!” they’ll claim. Well, that’s right, but often you aren’t using 100% of the features they offer in their platforms. Most of the time in my experience, you just end up using one aspect of their framework.

Consider using ad mediation to reduce the number of SDKs you need to import.

ake the time to go through their SDK and look at what you really need. Can this be simplified? Can whole files and assets be removed if you’re not using them? Some times, some frameworks will bundle in whole SDKs you aren’t even using at all, can you remove them completely and still have your app run fine?

Download new assets from web

I like to call this “Cheating”!

Sometimes I’ve downloaded a game under 25mb, then when I open it up it wants to download “Extra content” at each new area. Suddenly, it becomes a 100mb+ game on my device!

Don’t get me wrong, cheating is a good thing! Well, at least, it isn’t a horrible idea. Allow players to download and do something with a small download, then if you can’t live without those extra assets, make the player download them before going to new areas.

If the player hasn’t unlocked or doesn’t want to visit the Jungle world, don’t download those assets. This allows the player to get going faster, and the app size to scale with the content they’re actually using rather that every potential place they could go to.

However, there is a major problem to this. It requires an internet connection to unlock new content. This could cause horrible player experiences if they don’t want to use up their 3g bandwidth bill, or don’t have access to WiFi. When a players forced to download something and they can’t or won’t, they may rate the game poorly due to “Lack of content”.

I would only recommend doing this if it’s completely optional game content, or if your game already requires an internet connection (like a multiplayer only title, or only download during an in app purchase).

Remove temporary files

Speaking of downloading extra content from the web… When you’re done, clean up after yourself.

If you app is ever generating or downloading files (Save games, internal images/screenshots, extra data, etc), keep close track of them. Likely, your users will never notice or care until one day your apps ballooned to such a huge size it ends up first on the chopping block when they go to uninstall.

Pay attention to what files are necessary, and which can safely be removed. Have code to clean up temporary files, even if the app crashes/was suddenly closed last time it was used.

While testing you may constantly install, uninstall, and reinstall your app again, but in the wild a user will likely only install your app once per device they use. You don’t want to accidentally bloat over time.

What did I miss?

I hope this advice was helpful to some of you! I’m sure there are lots more tips and tricks out there for reducing file size. If you know one that I neglected to mention, please send me a message! If you’d like to read more of my writings, you can find me on my blog (where this was originally posted) at TobiahMarks.com.(source:gamasutra)


上一篇:

下一篇: