The culture of our development team has been a positive factor that has helped nurture the growth of this project. I always wanted this project to feel like a collaboration between real people, not just screen names. In the early years, I made an effort to call everyone on the project by their first name. I can’t do this anymore due to the sheer size and volatility of the team. In fact, I completely forgot that I used to do this until I started reading through some old forum threads when researching our history to write this series of posts.
Another important aspect to our team’s culture is ownership. I have never wanted anyone to feel that they are working on “Roots’ game”, but rather that they are working on their game. I wanted people to have ownership on this project, and to that end I encourage others to share their ideas for features, quests, and so on. If people feel like they can guide the destiny of this project and not just be a brick-layer for its predetermined path, they are a lot more invested and excited about the work that they are doing. Giving people a feeling of ownership hasn’t been easy, and some people on the team were flat out uninterested in design and simply wanted to make art, write code, or otherwise exercise their talents and abilities.
One of the biggest challenges with a free project like Allacrost is finding talented and motivated individuals willing to contribute their time. We do not pay a salary or promise any sort of financial reimbursement to our team. How can we attract volunteers, especially when there are comparable projects to ours that are for-profit? My answer to this question was simple: make sure that people are enjoying the work they do. If people are unhappy or frustrated with the project, they will leave. This policy is still in effect today and all new contributors read about it when joining the team . But it’s not perfect, and some great people certainly have left this project in the past due to feelings that prevented them from enjoying working with us. While we can’t make everyone completely happy on this project, but we sure as hell try.
After our initial team had finished our first series of design discussions and we had a better idea of what we were building, we began our first efforts to seek out additional help. They were wildly successful. Despite not having an experienced team or anything to show for this project, a lot of people were attracted to the type of game we were building and the ideas we presented and wanted to be a part of it. Our recruitment process was very formal in the early days and was almost like applying for a real job. There was a questionnaire that we required every applicant to fill out, then we would share their answers privately amongst the team and discuss the applicant. If no one objected to hiring them and they seemed like they would fit in, we welcomed them aboard.
One of the goals of this formal hiring process was to weed out people that lacked the qualities that we felt they needed to be successful. This could be any combination of experience, attitude, motivation, or other factors. It worked out well for the most part and the majority of the people we brought on the team met or exceeded our expectations. It wasn’t a perfect system though, and we did have some members that were not useful, or even downright damaging to the project. We hired one programmer and one artist in September 2004 and neither of them ended up working out. Here are their stories.
The artist we hired was producing great work that was very promising, despite his extremely young age. When another artist created an improved version of his work, he took it personally and got very offended that someone else would touch his art. Despite reminding him that this is a collaborative effort and that he should have read about this in his welcoming e-mail, he refused to accept the situation and promptly left the project. It was a shame as he was very talented, but not mature enough to work on a collaborative project like ours. It remains the only time we had an incident like that with a team member.
The programmer we hired immediately started making all kinds of destructive changes to the code as soon as he was given access to our code repository. He was scolded for making so many changes to our code policies and structures without first consulting other programmers to get their approval. As a result of this, we began being more careful about granting people commit access to the repository. He was tasked with developing the battle system for the game, which didn’t yet exist at that point. He repeatedly promised and failed to deliver anything for months. Eventually, the team dismissed him and he ultimately was just a hindrance to our progress.
The positive culture of this project was one of the reasons for its early prosperity and its continued survival throughout the years. We were extremely lucky to find so many talented and dedicated people in the first year of this project’s history. These early successes still influence the project today.
 - Allacrost Team Policies
Coming up next:
- Dealing with reduced availability
- Readjusting project goals to be more realistic
- Summary of 2004