Flash - 管理大型项目
我们使用 Autodesk Scaleform 进行原型设计，并使用 Flash 构建游戏 UI。我们需要能够由 3-4 名艺术家和 10 多名程序员组成的团队来运行一个大型项目。我们使用 Perforce 源代码控制系统来存储所有代码和资产。我们需要能够管理具有多个共享资源和多人（艺术家和程序员）在屏幕和控件上工作的项目。
我们的问题如下：
我们希望能够创建皮肤图形自定义组件，例如按钮、滑块、复选框以及更复杂的控件，例如表格和游戏特定元素。 我们希望能够在一个位置共享图形资源，并允许多个艺术家和编码人员同时处理共享组件。我们需要将所有这些存储在 Perforce 源代码控制存储库中。
对于 AS3 代码来说，这一切都相当简单。它的工作方式与任何其他代码库类似，我们已经设置了 FlashBuilder 和 FlashDevelop 项目。
现在，选项似乎如下：
- 创建一个或多个 Flash 项目。这里的问题是所有资源都被复制到 AuthortimeSharedAssts.fla 中。这意味着，由于 FLA 是一种二进制格式，因此我们的源代码管理不能允许多个人同时编辑任何共享资源。
设置手动创作时间共享。这将允许在多个共享组件上工作，因为个人可以更新一个小的离散 FLA 文件，并且这将自动更新更大的共享库。问题是，这不允许共享图形资源，这意味着，如果艺术家更新图形，则不会过滤到单个 Flash 文件。
使用 XFL 格式。这将允许我们在签入源代码管理时合并文件，因为它们是纯文本，并且它将单个资产保存为单独的文件，这看起来很完美。问题是我看不到如何创建一个完全使用 XFL 文件的项目（即创建类似 AuthortimeSharedAssets.xfl 的文件）。
目前我看不到在 Flash 中运行大型项目的任何明显、合理的方法。但我们不能成为第一个做此类事情的人。
谁能帮助或解释我们应该如何做？
We are prototyping using Autodesk Scaleform and building our game UI using Flash. We will need to be able to run a large project with a team of 3-4 artists and 10+ programmers. We use Perforce source control system for storage of all code and assets. We need to be able to manage a project with multiple shared resources and multiple people (artists & programmers) working on screens and controls.
Our problem is as follows:
We want to be able to create skinned graphical custom components, such as buttons, sliders, checkboxes as well as more complex controls such as tables and game specific elements.
We want to be able to share graphics assets in a single location and allow multiple artists and coders to work on shared components simultaneously. We need all of this to be stored in a Perforce source control repository.
For AS3 code this is all fairly straight forward. It works like any other codebase and we have set up FlashBuilder and FlashDevelop projects.
Now, the options seem to be as follows:
- Create a flash project or projects. The problem here is that all of the assets are copied into AuthortimeSharedAssts.fla. This means that, because FLA is a binary format, our source control cannot allow more than one person to edit any shared resource at the same time.
Set up manual authortime sharing. This will allow work on multiple shared components because individuals can update a small discrete FLA file and this will automatically update a larger shared librar. The problem is that this does not allow sharing of graphics assets, which means that, if an artist updates a graphic, this does not filter down to individual flash files.
Use the XFL format. This would allow us to merge files when checking in to source control as they are plain text and it saves out individual assets as separate files, which looks perfect. The problem is that I can't see how to make a project, which entirely uses XFL files (i.e. makes something like AuthortimeSharedAssets.xfl).
At the moment I can't see any obvious, sensible way of running a large project in Flash. We cannot be the first to do this sort of thing though.
Can anyone help or explain how we should do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我想说 XFL 将是如此大的团队的选择，尤其是在使用源代码控制时。
据我所知，大多数 XFL 符号都以 .xml 形式保存在 LIBRARY 文件夹中。如果它们是导入的 jpg 或其他位图，那么实际的图像文件也会保存在那里。
然而，我无法嵌入字体并将其保存在这种格式下，这可能是一个大问题，具体取决于您正在做什么。解决方案是动态加载字体，如 此处讨论。这可能会给设计师带来一些不便，但考虑到项目中有这么多人参与时使用 XFL 格式所获得的收益，这只是一个小小的代价。
我还建议对项目的某些部分进行预编译（制作组件）。
我希望这有帮助。
I would say XFL would be the way to go for such a large team, especially when using source control.
As far as I know most symbols for XFL are saved as .xml in the LIBRARY folder. If they are imported jpgs or other bitmaps then the actual image file is saved there as well.
I have not been able to embed fonts and save them under this format however, which can be a big issue depending on what you are doing. A solution to this is to load your fonts dynammically, as discussed here. Which may be a slight inconvenience to you designers but a small price to pay when you consider what you gain using the XFL format when there are so many people involved in the project.
I would also recommend to pre-compile (make components) of certain parts of your project.
I hope that helps.
这可能不适合您的团队，但我会建议它，因为（根据我的经验）它是一种非常成功的项目管理方法。
在做出这样的大型部门基础设施选择时，深入了解并了解您想要阻止的问题是值得的。也就是说，请耐心听我的解释。
您面临的主要障碍是 1) 锁定和编辑无法合并的大型 FLA 文件，以及 2) 防止这些文件中的 MovieClip 和类出现重复/版本冲突。冲突可能是创作时冲突（FLA 具有来自创作时共享库的过时库符号）或运行时冲突（使用相同类的冲突版本编译的 SWF，导致运行时崩溃）。
根据我的经验，解决方案是 1) 在二进制文件 (FLA) 中放置尽可能少的代码，2) 尽可能晚地将类代码绑定到 MovieClips，以及 3) 编写应用程序代码来执行以下操作这种“后期绑定”得体。这意味着使用运行时库而不是创作时库。我不会为了合并而尝试将二进制文件视为文本的解决方案；相反，最小化并隔离它们在代码中扮演的角色。让他们分开。
如果可能的话，我建议您的团队使用以下策略：
这种方法有很多好处，但简而言之，它允许您的开发人员和美工人员独立工作，而不必担心类和艺术文件之间的版本控制冲突。艺术家从不使用具有代码的 FLA，而开发人员拥有所需的控制权，以最大程度地减少 SWF 之间重复/冲突的类定义的可能性。每个人都可以更加专注于自己最擅长的事情。
只要舵的首席开发人员理解我正在谈论的解耦策略，我使用这种方法进行的项目往往会进展顺利。对于超级冗长的回复表示歉意； HTH。
This may not be an option for your team but I will suggest it, as it has been (in my experience) a very successful project management approach.
When making big, department infrastructure choices like this it pays to get into the weeds and see the problems you're trying to head off. That said, bear with my explanation here.
The main hurdles you have are 1) locking and editing large FLA files that cannot be merged and 2) preventing duplications / version conflicts of MovieClips and classes within those files. The conflicts can be authortime ones (FLAs having out-of-date library symbols from authortime shared libs) or runtime ones (SWFs compiled with conflicting versions of the same classes, causing runtime crashes).
The solution, in my experience, is 1) to put as little code as possible in the binaries (FLAs), 2) bind the class code to the MovieClips as late in the process as possible, and 3) write your application code to do this "late binding" gracefully. This means using runtime libraries instead of authortime ones. I would not bother trying solutions that treat binaries as text for sake of merging; instead minimize and isolate the role FLAs they play in your code. Keep 'em separated.
If at all possible I would recommend your team use the following strategy:
This approach has many benefits, but in a nutshell it allows your developers and your artists to work independently with less concern for version control conflicts between class and art files. Artists are never working with FLAs that have code and developers have the control they need to minimize the likelihood of duplicate / conflicting class definitions across SWFs. Everyone gets to focus more on what they do best.
Projects I've worked on with this approach tend to go very well, as long as the lead dev at the rudder groks the decoupling strategy that I'm talking about. Apologies for the super verbose response; HTH.
我不能推荐 Authortime 共享，因为我无法使用项目中几个 SWC 中的所有组件。经过几天的调查，原因颇为奇怪。
当至少一个组件（例如对话框）使用创作时共享组件（例如按钮）并且共享组件具有实例名时，它总是抛出类型错误。只要您不将任何实例名称分配给您通过动作脚本链接并稍后在项目中实例化的组件内的共享组件，一切都会正常工作。
目标是将一个巨大的 *fla 分割成几个较小的，在创作时共享资源，以便在分割的较小 fla 之间共享更改，并且编译器（而不是运行时！）不会复制这些类。即使大量使用动作脚本链接和自定义基类，这也很有效。 （尽管停用自动声明阶段实例）编译器成功排除了由共享引起的所有重复类。您可以轻松地控制它，查看每个包含的 SWC。
为了简单地重现这个问题，你必须制作 2 个fla。每一个都有一个影片剪辑（例如，一个对话框）和一个共享剪辑。 （例如，一个按钮；一个 fla 与另一个 fla 共享该按钮）。分配所有组件actionscript-linkage。将按钮放在每个对话框上，并为每个按钮分配一个实例名称。将两个 fla 编译为 SWC，将它们包含到您的项目中并尝试实例化这两个对话框。其中之一将抛出 #1034 类型强制错误。删除（其中之一）按钮实例名称，它将起作用。
要获得印象 - 这里是屏幕截图（全尺寸）：
我的猜测是，只要没有设置实例名称，flash 就不关心按钮实际是什么类型，并将其视为但是当设置实例名称时，播放器会尝试将影片剪辑类型转换为指定类型。但由于某种原因，没有查看整个命名空间（？），而只是在 swc 中编译了对话框。我得出这样的结论是因为当按钮已编译到 swcA 但没有编译到 swcB 中时，swcA 中的对话框可以工作，但是不是 B 的对话，反之亦然。您可以通过重新编译您想要按钮所在的 fla 来“强制”按钮交换 SWC。
我还在极少数涉及超过 2 个 fla/swc 的情况下运行了它。但不知道为什么。也许我会进一步调查一下，但我已经浪费了很多时间。
我希望你找到一个好的解决方案（并发布它：P），因为我们和你有同样的问题。
€：如果您还更新了共享组件一次，则似乎会发生错误（仅？）
€€：并且仅当您在共享组件的另一个 fla 打开时导出 SWC（??）
I cannot recommend Authortime Sharing as I have not been able to use all of the components out of the several swc's in my project. The reason is after several day's of investigation rather strange.
At least one component (eg. a dialog) is always throwing Type-Errors when it uses authortime shared components (eg. a button) and the shared component has an instancename. Everything works fine as long as you don't assign any instancenames to the shared components within components you've linked via actionscript and instantiate later in your project.
The goal was to split a massive *fla into several smaller ones, sharing the assets at authortime so changes are shared between the splitted smaller fla's and the compiler (not runtime!) does not duplicate those classes. This works great, even when using actionscript-linking and custom baseclasses massivly. (deactivate automatically declare stage instances though) The compiler successfully excludes all duplicated classes caused by the sharing. You can controll that easily looking into each included swc.
To simply reproduce the problem you have to make 2 fla's. each one with a movieclip (eg. a dialog) and a shared one. (eg. a button; one fla shares the button with the other one). Assign all components actionscript-linkage. Put the button on each of the dialogs and assign each of the buttons an instancename. Compile both fla's to swcs, include them into your project and try to instanciate both of the dialogs. One of them is going to throw a #1034 Type Coercion Error. Remove (one of) the button instancenames and it will work.
To get an impression - heres a screenshot (full size):
My guess is that as long as no instancename is set, flash doesn't care what type the button actually is and treats it as a movieclip but when an instancename is set the player trys to typecast the movieclip to the specified type. But for some reason doesn't look into the whole namespace(?) but only in the swc the dialog has been compiled in. I conclude this because when the button has been compiled into swcA but not into swcB, the dialog from swcA works but not the dialog from B and the other way around. You can "force" the button to swap swc by recompiling the fla you want the button to be in.
I also got it running in rare cases involving more than just 2 fla/swc's. But have no idea why. Maybe I investigate a little bit further but I already wasted quite some time on it.
I hope you find a good solution (and post it :P) because we have the same problem as you.
€: The error (only?) seems to occur if you also updated the shared component once
€€: and only if you export the swc while another fla with the shared component is open (??)
我现在遇到的问题和你几乎一样！我正在开发一款游戏，该游戏将所有图形资源存储在一个巨大的 FLA 文件中，该文件导出为 SWC 库。
我的问题是我们想要将这个巨大的文件分割成几个较小的文件，然后为每个新屏幕创建新的 FLA 文件。
我们使用 RSL 在不同的 FLA 文件之间共享资源。
例如。 fonts.fla 在库中导出了三种字体以供运行时共享。 Graphic_hsl.fla 包含高分列表图形并导入 fonts.swc 以供运行时共享。
您应该考虑 RSL，因为它们使您能够在一个文件中编辑图形资源，并且无论您在其他 FLA 文件中使用它，它都会自动更新。
我们尝试使用 XFL 文件格式，但最终我们切换回 FLA，因为版本控制对于 XFL 来说并不是真正有用。它具有非常复杂的结构，并且同时从两台不同的计算机更改文件几乎会破坏一切！所以不要与 SVN、Git 或任何你正在使用的东西合并！
I'm having almost the same problems now as you have! I'm working on a game that has all of graphical assets in one huge FLA file that is exported as SWC library.
My problem is that we want to split this huge file into several smaller ones and then creating new FLA file for each new screen.
We are using RSL to share assets between different FLA files.
Eg. fonts.fla is having three fonts in library exported for runtime sharing. graphic_hsl.fla contains high score list graphics and having fonts.swc imported for runtime sharing.
You should think about RSL as they give you ability to edit graphical assets in one file and it will be automatically updated whereever you used it in other FLA files.
We tried with XFL file format, but at the end we switched back to FLA as version control is not really useful with XFL. It has very complex structure and changing file from two different computers at the same time pretty much breaks things! So no merging with SVN, Git or whatever you are using!
还有一些更多的选择。我并不是说它们更好，但是，这取决于您的团队以及您可以投入多少资金来开发自己的开发工具...好的，这是 SWFMill 到 Haxe 的端口： http://code.google.com/p/hxswfml/ 。这允许将图形资源表示为文本 (XML) 文件。也许可以为 Incscape 添加一个插件来将图形导出为这种格式...然后我想 这些人有自己的格式和工具来管理视觉内容。 Flex SDK 编译器实际上可以很好地将 SVG 转换为 flash 图形。
最后，如果我有足够的时间，我最有可能研究的选项是 FXG 格式。 Flex 编译器可以编译该文件，但是，它仍然需要一些修补来删除 FXG 中所有与 Flex 框架相关的垃圾。然而，FXG 的好处是 Photoshop、Illustrator、Indesign 等程序可以导出为这种格式。当然，这大多是未经测试的......并且在某些地方我担心 FXG 是为最近暂停的 Adobe 产品（Catalyst）设计的。然而，该格式本身有可能仍然是 Adobe 程序的交换格式 - 因此您无需签入 FLA。
我与图形艺术家合作的方式：我们从不签入FLA，而是签入SWC，并制定一条规则，任何参与项目的人都需要签出并导入。当超过一个人需要处理同一个符号时，这并没有多大帮助，但是，至少，他们都在一个地方，并且如果您正在编辑不同的东西（大多数情况下都会发生这种情况），那么可以同时工作。无论如何，时间）。
There are few more options. I'm not saying they are better, but, depending on your team and how much you can invest into development of your own development tools... OK, here's a port of SWFMill to Haxe: http://code.google.com/p/hxswfml/ . This allows for graphic assets to be represented as text (XML) files. Maybe it would be possible to add a plugin for Incscape to export the graphics to this format... Then I think these folks had their own format and tools for managing visual stuff. Flex SDK compiler can actually decently translate SVG into flash graphics.
Lastly, and most likely option I would investigate, would I have enough time, is the FXG format. Flex compiler can compile that, however, it still requires some patching to remove all Flex framework related junk from what comes out of FXG. The benefit of FXG however is that programs like Photoshop, Illustrator, Indesign etc can export to this format. Of course, this is mostly untested... and at some place I fear that FXG was designed for the Adobe product that has been suspended recently (Catalyst). Yet there is a chance the format itself will remain the interchange format for Adobe programs - thus you will not need to check in the FLA.
The way I work with graphic artists: we never check in FLA, instead, we check in the SWC and make it a rule that whoever works on a project needs to check it out and import. This isn't really helping when more then one person needs to work on the same symbol, but, at least, they are all in one place and it is possible to work simultaneously, if you are editing different things (which happens most of the time anyway).