pen-pen2002 wrote:At the end of the day, the proccess is more important than the final product. For me Intrumentality: Animasia isn't a video. It's the freinds I made along the way, it's mutal respect. That 74 page thread in this forum is Animasia as far as I'm concerned. And I wouldn't trade the experience for anything else I have done, or will do, in the AMV world.
Awww.....that's so cool
. Thank you, Pen-Pen.
One a more technical note, I've a few bits of advice to give, in no particular order:
- Be prepared to work with people a hell of a lot more skilled than you are. Unless you're AD or Scintilla, or some other such expert, chances are very good that you'll realize at least some of the other people in your project are more talented or more knowledgable than you are - and that there are times when the best artistic role you can play is to stay out of the way and let them work their magic.
- That new edit functionality would have been very useful in the early stages of Instrumentality/Animasia. Back then, we actually did
have to try to keep up with every new post in the thread (and it's a very long thread) to know what was going on as the (originally very fuzzy) requirements changed or were clarified. Now that you can do edits, I highly suggest putting up a "quote" box (attribute one to "Guidelines" and another to "Status") somewhere in the opening post where you keep:
the current version of all of the project rules
a list of project members
a 'tracklist" representing the temporal arrangement of everyone's segments, or at least a draft of that arrangement
a status list for what parts are done and what parts need to be done
notes concerning anything that was changed and why the change was made
- DO try to get to know the people on the project, especially if it's a long-term one. You'll find that having some impression of their personal style, interests, and way of interpereting things will go a long way toward being able to smoothly direct the project - and to, as Pen-Pen said, make some friends and enjoy the process.
- Try to set some schedule for when parts of the project will/should be done - but be prepared to alter that schedule as all of those little details called "reality" come into play and slow things down. Your approach to scheduling should also take into consideration what you are producing. In the case of Instrumentality, we weren't trying to have it ready for any specific convention or contest, and are more concerned with giving everyone who wanted to submit something ample time to get it done and with making the final product something polished that adds something beyond the sum of the parts to the whole. Other projects, however, might have a hard deadline to meet - and these should have a more rigid but clearly predefined schedule so everyone will what the cutoffs are for joining and what has to be done by when.
- Try to figure out the technical details of how you're going to compile the project before you actually have all of the footage for compilation. It will save you a lot of headaches if you start digging through man pages (um, I mean "help files" - for the commercial OS peoples) and internet tech forums looking for the best possible way to transcode and combine the project files. If anyone wants to ask me how I've been doing it, I'll be happy to get into a detailed explanation
. I will say right now that it's possible to combine MPEG1 and MPEG4 streams without re-encoding them if they are in the same encoding - in other words, you can compress everyone's lossless / extra-high-quality renders (adjusting framerates, aspect ratios, display resolutions, and applying some smart artifact-reducing filtering as you do so), and then
combine the footage. This knowledge is, of course, the product of realizing that I couldn't store a losslessly encoded two-hour film and
all of the files it is made out of on my hard drive - as I learned the hard way by trying to do so, only to run out of disk space.
- Keep it simple. You'll have a lot of grandiose ideas of what can
be done - and chances are that you're right, it can be done. Just not by you, not it the timeframe you have to work within, with the tools you have at your disposal. I think there was one point in the Instrumentality project where I thought I was going to do a 3D render of a beautiful studio with moving strips of film gathered from all of the videos scrolling all around the background like one of those "strange attractor" diagrams in fractal picturebooks, with a different talking animated character in every narrative lip-synched to every word in every narrative. If I wanted to drag the project out for another year so I could try to figure out Maya on my roommate's computer when he's not using it to work on his own 3D animation assignments - this might be a good idea. Since I'd like to actually finish the project, however, I settled upon a 2D "set" scheme that was still attractive, but a hell of a lot easier to make and to make look good.
- There were times when I wasn't all too convinced that everyone actually had anything
put together for their segments - but, as it turns out, some of us like to post things in versions, and others pretty much didn't want to show anything until they felt it was ready to be seen. Since some great videos were made both ways, I don't there's anything wrong with trusting your project members to come up with something wonderful, even if you haven't seen it and they haven't really explained what they're doing.
- Don't try to decide everything by referendum. Doing this this way gives the other members more "say" in the project's final form - but takes a long time and often leads to confusion as to what the group consensus really was. I guess I'd suggest that you say "here's what I think we should do", and welcome comments and criticizms. That way, there's at least an original plan and you'll only have to worry about changing it if it really does clash with what one or more other people on the project think should be done. I am, by the way, talking about artistic decisions. Technical decisions (frame rates, encodings, aspect ratios, resolutions...) really should be mandated up front, and then you should help anyone who has trouble meeting one of them to find a way to do so.
- It'll take up more of your time than you probably expect. "Managing" doesn't really take all that long - but you also have to consider the number of posts you'll be reading so you'll know what going on, and the number you'll have to write so everyone else knows what's going on. You'll probably also have to do a fair amount of technical research as technical issues arise, and chances are pretty good that you'll be spending some more time on content creation (as I was with me video segment, and now am with all of the "glue" sections). You really should also expect part of the time you spend on the project to be social - which I consider a good thing, but is something to consider if you are already working on a tight schedule.
- You should establish a convenient way to exchange project files (video previews and such) and information as soon as possible. FTP seems to be a good system for handling files, and keeping all of the project communication in your project thread eliminates any issues you might have with trying to keep track of who knows what, and who needs to know what. You should also try to come up with a backup plan for the file exchange if the main method becomes temporarly or permanently unavailable (FTP mirrors, for instance, which were a big help for two points in the Instrumentality project where I was unable to keep my own FTP server up).
- A web page might be a good idea. Try to make it better than the one I came up with. Also try to keep it in synch with the Forum (I didn't do that, either). Come to think of it, now that you can edit you r first post, the web-page thing isn't all that great an idea unless you're thinking of it as more of a promotional thing.
- Don't "dissapear". If you know you'll be swamped and unable to follow communications for a while, at least say so. This way, you can take a break when you need to without anyone thinking you've abandoned the project.
- If you're doing something that's taking a long time, and that doesn't lend itself to being posted somewhere for the participants to take a look at how it's coming along, you should probably give periodic textual updates of what you're doing so the other members know what's going on and have a chance to give you their suggestions.
- When you think someone's done a great job on something, say so. It seems obvious, but we all sometimes forget and take other people's talents and efforts for granted, so do your best to thank them for what they've been doing and point out a few outstanding points of their work. This also has the benefit of defining quality targets that are much more clearly defined than "it should look good, and be creative". It's a lot better to be able to, for instance, evaluate your final encoding quality as related to "Forbidden Memories" because "Forbidden Memories" is a very well-defined example of "it should look good". It is also sometimes a good idea to ask how someone did something that you think is really great - because you can learn a lot this way, and it might be something that other people can in some way apply realizing their own artistic visions.