How to produce assets effectively on large Flash game projects?

Question

I have been working on Flash games professionally for two years now and somehow, having our artists producing assets the right way is one of our biggest challenge.

More precisely, it is very hard to have them following any kind of structure and/or standards, nor taking into consideration performance. I would say also the most of our issues concerns UI and related animations.

Our current workflow is (on a Facebook hidden object game) :

1. Artists produce PSD and animate prototypes in Flash
2. Artists re-organize their FLA files to be a bit more "programmer friendly"
3. Programmers retouches assets until they have the right structure and export classes inside a SWC, from Flash
4. Programmers try to improve performances, sometimes degrading the quality of game graphics

Our main idea is to hire somebody dedicated to prepare assets for programmers but I am really looking forward to improving the pipeline.

I was wondering if you guys have tips of any kind to improve this workflow, whether it be team organization, training, tools or tips with Flash. Any explanation on your asset pipeline is well appreciated too.

EDIT :

Thanks for your replies. I do agree with you that tools and processes will never replace collaborative people. However, I feel like we got stuck into this "I am doing my own thing" mentality as the integration process caused a lot of friction. As part of our Scrum process, the team clearly acknowledge its own quirks and was looking at immediate solutions for the next project : better rules, better attitude, better understanding of each other.

My team have specialized artists (UI, character drawing, character animation), but no leading art director (we use existing licenses/brands), and programmers (both front and back end). That's why having a very versatile person in between (designer, integrator, technical artist or however you want to call it) is invaluable in my opinion - so, I am looking for innovative solutions.

Usually, the main specs/requirements for assets are :

• Naming (of classes, textfields or various visual objects that will be used by the code, taking in account that visual needs can cause deep nesting of objects)
• States (that we implemented with frame labels)
• Alignement (always build from 0,0 - use round values)

So, while adopting "good practices" can sure help, there always is this little part of feature-specific requirements that has to be decided. Basically I was looking for a an efficient way to communicate these specs (even to non-technical people) and avoid the back and forth to verify assets are as expected (this is where my idea of intermediate validation format comes from).

I understand there is no clear answer and I created this post to get people feedback and good ideas (it's working so far :)

Answer 1

Rules/processes are key, but just sticking a set of rules on the wall will not work.

• A good production team lead (having found out developers' need in terms of assets) should sit with artists to go through these processes, since a team lead's job is to facilitate work, whereas a developer's job is to do work. Developers should never, ever touch assets (just as designers should never touch code). Once they do, the balance starts to shift unfavourably towards artwork, as artists have more time on their hands, and developers, less.

• Rules don't enforce themselves. You need to establish authority and discipline for your rules to work. "Understanding" is not the same as "trying to understand", so "I don't understand" is a very limited excuse. I have seen artists on many of my contracts choose not to obey set rules because they do not see these rules as impacting them personally, so why bother? Until such time as there is an impact, compliance will fall by the wayside; most artists see their job as "being creative", not as "following rules". So you need to make it clear how important it is, by rewards and, if you're evil, also punishments. Get senior management support if necessary.

• On the start of a section of work, have an inclusive meeting where artists are expected to participate as part of the overall production team by getting involved with what output specifications are required and most importantly ask questions about why. Artists who are more involved should be rewarded in some way (buy them a six-pack as a monthly prize, for instance) aside from the social benefit of being well-liked by the programmers. Have these meetings only for as long as it is necessary to bring artists up to speed with process, i.e. avoid wasting production time on meetings.

• Once this knowledge has been imparted over a period of time, from developers and team leads to artists, it will largely become second nature to the artists.

Answer 2

To me it seems you have a communication issue, rather than something that can be fixed by using tools or adding a person to the team to correct the mistakes your team makes. It's best to prevent making mistakes by improving your communication.

The designer

I'm going to assume (for now) you have a designer. (Not the same as an artist!)

The designer maintains a creative vision of the final product, and determines what assets are required to put that vision together. The artists then create the assets according to the specs (dimensions, file type, etc.) the designer provided, and the programmers implement the gameplay rules and include the artwork into the code.

Basically, both the artists and the programmers work for the designer. The designer acts as a go-between for the two disciplines, and needs to know both the technical and the artistic limitations, and keep the user experience in mind at all times.

Collaborate design

Now, if you don't have a designer, it's a little more tricky. That means your entire team needs to act as a designer in a collaborate way. You should plan sessions to discuss what features are required, what art assets are required to implement those features, and how best to implement them.

The most important thing is that you write down everything you agreed upon; what has to be implemented before the feature is considered completed, and what technical requirements it has to conform to.

Mixing both styles

You can have both a designer and design your game in a collaborate way. This allows for more creative input from both the programmers and the artists, and often results in ideas the designer did not think of. It also helps to communicate both the technical and artistic limitations to all three disciplines while having the designer maintain a clear product vision.

Further reading

For further reading on collaborate project management, I suggest looking into Agile, Scrum and Valve's Cable methods:

• Agile Game Development With Scrum, by Clinton Keith
• Valve Handbook for New Employees

Answer 3

The flash games I've been working on recently (isometric browser games where players get to build their Farm, Park, Zoo, Whatever) used a combination of animated SWFs, spritesheets, PNG's and procedural, bitmap-filled API rendering.

Only the animated SWFs were authored in Flash by artist, the rest of the game, as far as Flash is concerned was created in Flex Builder by programmers.

To get the assets into the project we set up an asset pipeline generating and compiling code that would make heavy use of the [Embed] tag but saved us the hassle of embedding assets manually. Here's some additional info if the idea interests you.

Performance issues related to assets are quick to resolve that way. You just tell the artist responsible for a problematic asset to redo it. We didn't care for how messy their FLA's were as long as the exported SWF would look good and be reasonable in size and performance.

Answer 4

I think I'd start with creating some kind of basic set of rules every designer has to follow. I'd do this with programmers and artists together so both can give you input and you try to find the best compromise between beautifull artwork and usable art. This set would contain all the "rules" for creating optimized art which doesn't look crappy and is programmer friendly, but also doesn't look extremely well but loads to slow due to huge file size etc.

If your artists can follow this, there is no need to refactor the animations etc later on. It can be very usefull to have a dedicated "art preparer" but it seems quite expensive. I'd try to create more understanding on both "teams" and better define the possibilities and impossibilities to both sides.

Answer 5

I will go by giving a possible answer to my own question. However, I won't mark it as the "right" one now since I have never tried it and some others answers are possible.

Some developers have developed a set of GUI extensions for Flash to allow designers to produce assets using custom rules or formats. More precisely, these provide:

• Snippets accessible through a comprehensive GUI to speed up repetitive tasks
• Metadata through naming of instances or layers
• Export routines assets in the desired format

Thanks to JSFL, it's possible to speed Flash asset creation, and it's even easier with xJSFL. Here's an example of that.

I was also thinking that one could add routines to "verify" the structure/naming of assets, by having some sort of descriptor file that would be the agreement between programmers and artists.