(some of) What Emor Learned ...about Age Building as a team

Project Structure

Adrael's growth as a project was largely an organic, learn-as-you-go evolution. The storyline, underlying concepts, and appearance were not all established prior to building each section of the Age. In part this was due to the fact that for several participants this was their first Age project, and for others it was their first group Age project. At the time this was a practical way to work, since we could achieve small successes and then decide whether we wanted to continue building upon those steps. It was also necessary because there had to be a give-and-take between creative fantasy and the real-world practicality of what the team could achieve technically. Form was, more than once, determined by the function of what we learned could (or could not) be done with the tools we had available!

Even the final area of Adrael's progress - still incomplete in the early release currently available - was added as an afterthought when we realized that players might not return to see the payoff of their efforts, and to give the Age a bit more of a spectacular finale.

There may be advantages to doing all design work up-front, before any real construction work begins. On the other hand, we've all seen many projects get bogged down in endless pre-production design conversations, haggling over minutiae. In many cases, no real work is accomplished, or the team becomes disillusioned when the real work doesn't match their now-escalated expectations.

In retrospect, it seems like the best approach to agebuilding - for fan work at least - would be to have all the game's essential puzzle and play steps completely established and structured in advance, making sure all puzzle coding could be successfully achieved. Then all the design and construction of the physical Age can be hung from that framework, in (relative!) confidence that this work is not going to have to be thrown away due to technical considerations or a general lack of a Master Plan.

Team Hierarchies: pros and cons

Adrael had the advantage of development within a very insular group of Myst/URU fans. Adrael also had the disadvantage of development within a very insular group of...well, you get it. All in all, the Adrael team was very supportive of one another, and the Age development process was a huge pleasure to watch and to participate in, for myself at least.

One of the areas in which there was disagreement within the group, it later turned out, was on the topic of group hierarchy: the pecking order. At least two of the group's members firmly believed in the notion that a top-down structure was essential to a project's survival and success.

And there's nothing wrong with that belief, I think. Some people simply work best knowing exactly where they stand in the order of things. For some it is mandatory that they must be a "leader" type, others feel they can work only under a leader.

Some in our group, who had worked a lifetime in the arts and design fields, were more accustomed to a workstyle in which project participants might have a predominant role or even a nominal title, but in which there is a large degree of exchange of roles and ideas: working environments in which discussions improve the end result.

Certainly in corporations or the military, hierarchical structure is considered essential. But in both those situations, one thing is key: the participants are paid!

In an all-volunteer project however, there are very few rewards. Some of these rewards might be

• Seeing the pleasure others take in enjoying your finished work
• Getting a little bit of credit for the effort you've put into the project
• Collaborating with friends, making friends with your collaborators
• Learning from your project co-workers and enhancing your own skillsets
• Seeing your ideas become reality (virtual though that reality might be!)

The first three items should be possible in either a strict or loose project hierarchy.
But there have been very few times I have learned art or software techniques from a boss when working in a strict hierachical setting; likewise when I have worked in supervisory positions I have rarely had the time or inclination to teach; one expects employees to already have their necessary skills.
And in a top-down project structure, unless you are at the top you will not see your ideas become reality. You will be working to make someone else's vision a reality. This subjugation of one's own vision - to use your skills to make another's vision reality - is (usually!) what people are paid for.

Does this mean that one shouldn't volunteer to assist others in making their visions come to life? Not at all! In fact, since Clat wrote and designed perhaps 80 to 90% of Adrael, we all did this to assist him, in a way. The difference here was that, if I disagreed with a direction the project was taking, I felt free to voice my opinion about it, or to ask some pointed questions to determine if this was really the direction everyone wanted to go. Sometimes my opinions made a difference, other times I was overruled. But after stating my feelings once, in each case I went along with whatever the consensus dictated.

For myself, I think it's essential in an all-volunteer project that we work more as equals, respecting one another's skills, ideas and dedication.

Schedules

Just as with our team's differing concepts on project hierarchies, it turned out we had different concepts of project scheduling.

Now, some projects may be blessed with participants who either have near-infinite amounts of free time, or these individuals may have very structured lives that are not often disrupted by work or family demands. But for most of us, our free hours ebb and flow daily, weekly, monthly.

Again, if we were paid as agebuilders then schedules can and must be established and met. But any such long-term demands are completely impractical for all-volunteer projects, in my opinion. Only small steps can be scheduled, and even these must be met with understanding by the team if they occasionally fall behind projections.

Additionally, some of Adrael's key participants strongly felt that one year, or maybe eighteen months, was the absolute life term for an Age project, beyond which it must not continue. Most of the remainder had no such restrictions.

Quality

"Quality" is, I feel, a subjective term without any objective definition, and the reason for a lot of insanity (including that of not a few authors!)
However, in agebuilding the term "Cyan quality" is often used as a handy reference point. And imperfect as Cyan's ages may be, I think we all generally understand this term to mean an age in which enough attention has been paid to modelling, texturing, lighting, sound and detailling such that a level of plausibility, a "suspension of disbelief" can be established.

It was the topic of quality that, I believe, caused the most dissension within our group. Some participants were satisfied to make an Age that was simply playable, others had a strong desire to also make a visually compelling Age.

So...what's your point?

So, looking back at our own project, it seems that it might have been beneficial if all prospective participants had established from the outset that they were in agreement about key project principles, such as:

• how the project's game structure would be developed: up-front, or as an organic evolution over time?
• whether the project would have a strict hierarchy of project head and department heads etc., or a looser organization in which participants with certain strengths might take the lead in those areas but suggestions and contributions could come from all players?
• does the prospective participant have restrictions or expectations about the project's short-term or long-term development or release schedule? If so, these limitations need to be firmly established at the outset.
• is the participant content with a basic Age that contains just the essential form and simple texturing necessary for playability, or are they willing to put in the (sometimes less-rewarding) extra effort to turn that basic structure into a plausible environment?

These are some of the factors that can help define the operating principles of an agebuilding project before the real work begins (or can help determine whether newcomers to an ongoing project are well-suited to its already-established direction.)

Fortunately, the remaining Adrael participants all seem to have a good agreement on these factors!

Emor D'ni Lap, April 2011