Developing a fangame on your own is a challenge. Developing one with a team is a different challenge altogether. People often assume that having a team means the project will move faster. Sometimes that's true... but only if everyone understands where the project is heading and how they can contribute. Otherwise, a team can quickly become a source of delays, misunderstandings, and lost motivation. Before recruiting anyone, ask yourself one simple question: > **Is my project ready to welcome new contributors?** In many cases, waiting a little longer before recruiting is the better decision. ## Don't Recruit to Solve a Motivation Problem This is a very common mistake. After several months of development, motivation starts to fade. You begin thinking: > *"If I recruit more people, the project will get back on track."* Unfortunately, that's rarely how it works. A team doesn't create a vision. It contributes to a vision that already exists. If you're no longer sure where your project is going, your future contributors will most likely feel the same way. ### Example 1 :::danger[Avoid] Posting an announcement like: *"I'm looking for a team to create a Pokémon fangame. I have lots of ideas."* ::: People who are interested will have a hard time understanding what they're joining. :::tip[Instead] Present a project that already has: - a clear direction - a few screenshots - a first demo or prototype - a list of specific needs ::: Contributors will immediately understand what they're signing up for. ## Recruit When You Have a Need It can be tempting to recruit someone simply because they're talented. But if you don't know what they'll actually work on, there's a good chance they'll eventually drift away from the project. Before every recruitment, ask yourself: - What do I actually need? - What tasks will this person be able to work on? - Who will review and validate their work? - Will I have enough time to help them get started? The more specific your answers are, the smoother the onboarding process will be. ## Small Teams Are Often More Effective There is no perfect team size. However, very large teams are rarely necessary for an amateur project. Every new contributor requires: - time to explain things - communication - feedback - coordination Before growing your team, make sure the people who are already there have enough work to do and all the information they need to contribute effectively. A team of three well-organized people will often accomplish far more than a group of fifteen people who rarely communicate. ## Make the First Steps Easy Joining an existing project is never easy. Even with the best intentions, a new contributor doesn't know your world, your workflow, or your tools. Take the time to explain: - the project's goal - how the project works - the tools you use - where important information can be found - how to submit their work There's no need to explain everything at once. A few well-chosen resources and a small first task are often enough to help someone get started successfully. ### Example 2 :::danger[Avoid] Giving a brand-new contributor a major task before introducing them to the project. ::: :::tip[Instead] Start with a small contribution. This allows the new contributor to gradually discover the project while giving both of you time to learn how to work together. ::: ## Build Trust... Gradually Volunteer projects are built on trust. But trust isn't automatic. Give people time to find their footing. Pay attention to how they communicate, how they organize their work, and how they respond to feedback. Over time, you'll naturally feel more comfortable giving them greater responsibilities. This gradual approach benefits everyone. It avoids putting unnecessary pressure on new contributors while helping keep the project stable. ## Feedback Is Part of Development Nobody produces perfect work on the first attempt. Giving feedback isn't about criticizing a person. It's about improving the project together. Whenever possible, explain your feedback. :::danger[Avoid] Saying: "This map doesn't work." ::: :::tip[Instead] Say: "Players may have trouble understanding where they're supposed to go. If we widened this path, the map would be much easier to read." ::: Constructive feedback is much easier to understand and much easier to accept. Using **"we"** instead of **"you"** also matters: improving the project is a shared responsibility. Likewise, when someone gives you feedback on your own work, try to see it as an opportunity to improve your project. ## Recognize Every Contribution In an amateur project, everyone is contributing their free time. A simple "thank you," a quick review, or highlighting someone's latest work can have a huge impact on motivation. Small gestures help maintain a positive atmosphere within the team. They remind everyone that every contribution matters. ## Remember That Volunteers Have a Life Outside the Project Your teammates have school, work, family, and other hobbies. It's perfectly normal for their availability to change over time. Avoid putting unnecessary pressure on people. Instead of expecting work to be delivered by a specific date, check in regularly to see how everyone is doing. Most volunteers stay engaged because they enjoy contributing. Excessive pressure, on the other hand, often leads people to step away from the project. ## Conclusion Here are some common challenges we regularly encounter in community projects. - Recruiting before having a clear vision for the project. - Trying to build a very large team from the very beginning. - Giving major responsibilities to new contributors too quickly. - Assuming contributors automatically know how the project works. - Giving feedback that is vague or only negative. - Expecting volunteers to have the same availability as professionals. - Forgetting to thank people or recognize their contributions. A team doesn't move a project forward on its own. It's trust, a shared vision, and good communication that allow everyone to do their best work together.