作者：Maria Sifnioti

资产命名规则反映相当简单的理念：如何命名资产或资产组成要素。但若是跳至相关规则的遵守，就不那么简单。本文将以《Maya’s Dress Up》为例，所举例子主要侧重图像资产，但这里所述的内容也同样能够运用至其他富媒体。（请点击此处阅读本系列上篇）

Assets from gamasutra.com

采用能够自我描述的名称

简单有效的方法是，确保仅凭名称，大家就能够把握道具的内容。这里的“大家”不是创建及命名文件的相关人员，而是指其他需要利用或参照此道具的团队成员，或现在，或未来。

例如，文件名“bigboss1.obj”就不够富有描述性，“final_boss_lvl_01.obj”是更好的选择。

在《Maya’s Dress Up》中，我们通过Garment词条指示任何Maya的穿着物，包括各种发型、衣着或手镯。服装资产以目录结构保存：

* Wardrobe/Accessories/Gloves/

* Wardrobe/Bottoms/Cropped/

当我们开始着手游戏时，衣着就会由完整路径指示，例如一副深红色皮手套的路径将会是“Wardrobe/Accessories/Gloves/Fur_Crimson”。

游戏发行一段时间后，我们发现此命名模式效率不高，我们决定采用文件名作为标识符。这带来相关问题，我们现在面临双重文件名问题：

* Fur_Crimson（源自Wardrobe/Accessories/Gloves/的一副手套）

* Fur_Crimson（源自Wardrobe/Accessories/Scarves/的毛皮围巾）

我们的失误在于名称缺乏自我描述性。我们没有设定持久性的衣着命名规则，但我们重视颜色命名。讨论过后，我们决定采用如下规则：

（材料，如天鹅绒）+（风格，如Tank）+（子类型，如经裁剪的或无袖的）+（类型，如上衣或短裤）+颜色

如今合理衣着命名需要具有描述性，例如OvalBuckleBelt或SuedeJacket。

我们不需要同时运用所有元素，但最终名称需要具有描述性。

完成这后，整个衣橱需要进行重命名——遗憾的是，这将带来以下工作量：

1. 重命名PSD文件中的所有图层（单个衣着约有5个图层，衣着数量数以百计）。

2. 确认名称的正确性。

3. 将所有资产转变成高质量内容。

4. 再次基于iPad、iPod/iPhone和Retina模式创建资产。

5. 创建关系表格（游戏邦注：旧衣着命名-新衣着命名），顺利地将玩家的保存风格转化到新格式。

我们显然从中学到许多，希望通过详述此内容，其他开发商能够避免这样的情况。预先计划，查看适合游戏的内容，避免其他的高成本付出。

巧妙而坚决落实规则

若你在项目资产的命名上设有若干规则，首先告知相关资产创建者。不要默认他们心中有数。

给予清晰指令，阐述为什么游戏元素需要以此方式命名。仅向他们解释Box01或Layer9绝对不行。让美工参与至整个资产制作周期中，陈述美工元素在后期发生什么变化。优秀美工会立即领会你的意思。反之则会给予团队工作带来消极影响。

在此命名事件后，我们给美工设定系列指导方针。我们陈述的内容如下：

美工完成图像元素后所发生的情况：

我们的任务是导出所有衣着元素，一种颜色一件，将其植入游戏中。我们清楚当美工进行着色时，各衣着就会融入多种层次。

下面是美工完成任务后我们需在各道具中进行的操作：

[将内容输入iOS平台所需的程序步骤]

遵照若干命名和内容组织指南，落实步骤1-5，你将发挥突出作用。这里我们将进行总结，然后详述其必要性及最终结果。

我们的指南包含此类内容：

将闲置图层放置于UNUSED组中。将群组标记上红色。

保持图层命名的合理性。不要将图层命作Layer15或Vector，或将它们集聚到合理的名称之下，或进行重新命名。

若你不想给美工压力，或者若你是团队唯一的设计师，想想下述情况：

5年后，你想要将资产重新植入新设备，但美工已经离开，或者5年里你没有打开PSD文件。你将毫无概念，图层56和Group 2指什么。

脚本作用显著

落实命名规则是一回事，但检验其执行情况则是另一回事。我们显然无法逐一查看图层或目录文件。

在某些情况中，例如PSD文件，我们通过Photoshop脚本检验内容。脚本基于正确文本名称加载文本文件，然后基于PSD文件进行检验。若图层的命名存在差异或无法找到，脚本就会给出警告。

处理文本文件需注意若干事项。

1. 确保脚本会检验大小写兼容性。OS X和Unix文件机制在此非常严格。

2. 避免文件名称出现空格，或者至少确保你能够恰当“避开”空白字符。

3. 当你采用文本文件时，确保它们以正确编码保存。DOS和Unix在保存结束行和EOF字符时采用不同方式，逐行分析文本文件会带来相应问题（游戏邦注：若文本文件未采用正确编码）。

4. 采用优秀文本编辑器，如UltraEdit。我推荐将UltraEdit运用至各种脚本中。

另一需要完成的任务是反复给各目录的文件重命名。若你有Windows系统，DOS批量脚本处理器是非常有效的操作工具。此工具能够进行条件及巢套叙述，是非常强大的工具。

未来存档

资产在创建后通常需要进行多次更新，直到最终定案。合理命名这些修正版本也非常重要，可以通过数字、日期或字母排列顺序，例如final_boss_lvl_01_rev.A.obj。但记住，要清楚标记最终运用至游戏中的内容，标上FINAL标签，将其移至IN-GAME目录，确保明确区分内容。未来你将需要反复运用这些资产，若你无法判断保存成品草图的文件，你将遭遇麻烦。

总结

文章内容可以总结成如下内容：

1. 腾出时间定义命名机制。

2. 给资产及其修正内容的命名和处理设定指南。

3. 告知资产创建者，落实命名规则。

4. 通过脚本处理及其他工具检查所有内容的正确性。

这些工作只需较少投入，但回报显著，能够帮你省下众多麻烦。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Managing Assets – Part 2: Setting Naming Conventions

by Maria Sifnioti

I’m Maria, the Associate Producer for Total Eclipse, a game development studio based in Thessaloniki, Greece.  This is the second part of the “Managing Assets” series of posts and deals with asset naming. If you are looking for the first part, on asset quality, you can find it here.

Asset naming conventions reflect a really simple concept: How to name assets, or parts of assets. However, when it comes to adhering to those conventions, it’s anything but easy.As with the previous post, I’m going to take a look at the conventions by using Maya’s Dress Up as an example. My examples will focus on image assets but what I’m going to say can again apply to other rich media.

Use self-descriptive names

The rule of thumb is that from the name one can understand what the item is.  When I say ‘one’ it does not mean you who created and will name the file, but anyone in the team who might make use of, or need to reference it, either now or in the future.

For example, the filename “bigboss1.obj” is not very descriptive, while “final_boss_lvl_01.obj” is surely better.

In Maya’s Dress Up we use the term Garment to denote anything that Maya might wear. This can range from a different hairstyle to dresses or a bracelet.  The garment assets are saved in a directory structure like:

* Wardrobe/Accessories/Gloves/

* Wardrobe/Bottoms/Cropped/

When we began work on the game, a garment was identified by its full path, for example the ID for a set of crimson fur gloves would be “Wardrobe/Accessories/Gloves/Fur_Crimson”

Some time after release, we realised that this was not efficient and we decided to use the filename as an identifier.  This created issues as we now had duplicate filename issues as:

* Fur_Crimson (the set of gloves from
Wardrobe/Accessories/Gloves/)

* Fur_Crimson (a fur scarf from Wardrobe/Accessories/Scarves/)

Our mistake was that the name was not self-descriptive. We did not lay out a future-proof naming convention for the garments, while we did pay serious attention to colour naming. After discussions, the following convention was used:

(material i.e. velvet)+ (style i.e. Tank) + (subtype i.e. cropped or sleeveless) + (type i.e. top or pants) +colour

Now, valid garment names would be something descriptive, such as OvalBuckleBelt or SuedeJacket.

Not all of the elements had to be used simultaneously, but the end name had to be descriptive.

Once this was done, the whole wardrobe had to be properly renamed – and unfortunately, this escalated to:

1. Renaming all layers inside PSD files (one garment has about 5 layers and there are hundreds of garments).

2. Validating correctness of names.

3. Re-exporting all assets to high quality.

4. Creating assets again for iPad, iPod/iPhone and Retina display.

5. Creating a relationship table (old garment name – new garment name) to safely transfer a player’s saved styles to the new format.

So, we certainly did learn a lot from this and we hope by explaining it, it will help you to avoid such a scenario. Plan forward and see what might work for your game to avoid extra costly (and perhaps boring!) work.

Enforce the rules kindly but firmly

If you have rules about how you want things named in your projects, tell the asset creators first. Don’t assume they will know what you want without you telling them so.  Psionic (“mind-reading” for those of you without a D&D disposition) powers are not out yet.

Give clear instructions, and explain why things have to be named in such a way. Explain to them that Box01 or Layer9 will simply not do.  Make the artists part of the whole asset processing cycle and describe what happens to the art after it leaves their hands. A good artist will immediately see your point. Doing the opposite negatively affects teamwork.

After the naming incident, we created a set of guidelines for the artists here in Total Eclipse. In it we say something like:

What goes on once the artist delivers the artwork

Our task is to export all those garments, one for each colour, to be used in the game. We know that when artists paint, each garment may have a lot of layers inside it.

Here’s what we have to do for each item after you finish:

[procedure steps described for exporting stuff for iOS]

You can help a lot with points #1-5 by following a few guidelines for naming and organizing stuff. We’ll summarise them here and then explain why we need them and what it is that happens.

Our guidelines then contain guidelines like:

Put unused layers in group UNUSED. Colour the group in red.

Keep layer naming understandable. Don’t name layers as Layer15 or Vector. Either group them under a sensible name or rename them.”

If you don’t want to pressure the artist, or if you are the sole creator and really can’t bother, think about this:

Five years down the line you want to re-export the assets for a new device but a) the artist has left or b) you haven’t opened the PSD in said 5 years. You will have frankly no idea what is layer 56 and Group 2.

Scripts are your friends

Enforcing naming conventions is one thing but checking that they are being followed is another one entirely. One obviously cannot be expected to look at layers or directory files one by one.

In certain cases, like with PSD files, we are using Photoshop scripting to check things for us. The script loads a text file with the correct file names and checks it against the PSD. If any layer is named differently or is not found, the script gives an alert. Check out PS-Scripts for a similar source. The site is a treasure-cove for Photoshop scripting .

Some things to watch out for when dealing with text files.

1. Make sure that your script checks for Upper/Lower case compatibility. OS X and the Unix file system are very VERY strict on such things.

2. Try to avoid spaces in your file names or at least make sure you ‘escape’ the space characters properly.

3. When you use text files make sure they are saved in the correct encoding. DOS and Unix save end line and EOF characters in different ways and parsing a text file line-by-line may lead to problems if it’s not in the correct encoding.

4. Use a good text editor (avoid notepad) such as UltraEdit. In fact I can’t recommend UltraEdit enough, for all kinds of scripting. I think I’ll write another post dedicated to level scripting and UltraEdit.

Another thing you might need to do is recursively rename files spread on different directories. If you have a Windows system, DOS batch scripting is a really useful (albeit sometimes frustrating) tool to work with. You can have conditional and nested statements making it a powerful tool. This site has a good overview and examples of commands. I am sure Mac OS X’s automator does something similar but I’ve never used it.

Archive for the future

When an asset is created it usually goes through many iterations (or revisions) until the end result. Naming those revisions sensibly is also very important. You can use numbers, dates, or the alphabet to indicate sequence, such as final_boss_lvl_01_rev.A.obj; whatever works for you, really. Remember, however, to always, always, indicate clearly what is the final product that was used in the game. Have the word FINAL attached, move it into an IN-GAME directory, but make sure the distinction is clear. You will need to use those assets again and if you can’t tell which file holds the rough sketch from the end result you’re looking for trouble!

Conclusion

Everything in this post boils down to this:

1. Take some time to define a naming system.

2. Set guidelines for naming and handling assets and their revisions.

3. Enforce the conventions by keeping the asset creators informed.

4. Use scripting and other tools to check that everything is correct.

It is a small investment that will pay off and save you big headaches in the long-term.

Well, this ends the second part of the Managing Assets series. I hope you enjoyed it, as always comments are welcome!（Source：gamasutra）