This list is by no means definitive, but by considering these points it may save you from some of the common pitfalls a mod team will face.
- Your vision has to be clear – The team as a whole must have the same clear idea of what you are making. Everyone should be able to sum it up in 2-3 sentences. The same end point is where you should all be heading. If the team doesn’t agree, you will just end up with at best 2 mod teams (after a split) or at worst a dead mod and nothing to show for it.
- Don’t get bogged down in details (yet) – The early days of brainstorming are great fun. So keep notes of ideas, but start working towards a firm overall plan. Most of the smaller decisions can be made later on down the line as the features are to be implemented. Many of these will change as other gameplay elements are finalised as well.
- Make your initial goals achievable – We all like to dream big. That is the most exciting part of modding (you “can” do anything). But the key to any large project is to set realistic milestones. Break down the final vision into phases. That way you and your fans see the progression happen, you all get something playable sooner, and most importantly, you don’t spend 3 years working on your 1st alpha only for the game to have long since died.
- Communicate clearly and often – We can’t emphasise how critical communication is within a team. Real-time communication in particular is the best way to build a true team spirit (especially when you are dealing with a diverse and multicultural team split across multiple continents and timezones with real-life commitments as well).
Make use of a team discussion board, set up an IRC channel, use a Google+ hangouts, Skype, TeamSpeak, it really doesn’t matter which. Just make sure you speak often and encourage people with any spare time to idle. Workflow improves, decisions can be made quickly and everyone gets to know each other and becomes invested in the project. Modders who don’t join in the day-to-day discussions rarely stick around.
- Form a clear team structure – Having a hierarchy isn’t essential, but knowing who the real workers are, who has the most experience, who make the most effective decisions and who has the greatest expertise in each field, makes decision making far easier.
Most teams will have natural leaders. Let these develop. Let people take responsibility for different areas of the project. A larger team like Pop Smoke has clear leaders for each key area of development (with each internal team having its own flexible but defined structure). So long as communication remains clear and frequent, then you can be a top down dictatorship or a true anarchist collective with no real leader. Just remember, when unsure, just put the options to a vote and let democracy decide.
- Get the right systems in place early on – Mod teams these days need a fairly complex infrastructure to work effectively. Our basic checklist would include a website, community forums, developer forums, a wiki or similar repository for ideas/data, real-time communications (IRC or Skype are most likely), SVN to bring it all together and an FTP to store all working files. There are more tools you may well end up using, but these are the essentials.
- Recruit constantly – You will never have enough developers, just accept this. The turnover on any unpaid project is always high. The real-world will often take from you the most talented of developers. Many will join a team and never contribute. Some may produce lots of nearly finished work, but never complete something before they disappear.
From the masses a core of dedicated modders will emerge. They will carry you through the quiet times; they will ensure progress is maintained even in the darkest days when hope grows faint. Despite their dedication (you know who you are guys) keep replenishing numbers as some will stick around and your core will grow until you have a functional team.
- Store everything centrally and rationally – People come and go, computers have occasionally been known to have problems. Can you really rely on every member of the team to securely backup all of their own work? What if that developer just disappeared before handing over that shiny new model you’ve been ogling over renders of for weeks?
All critical information and all key working files should be stored centrally. Get everyone into the habit of keeping assets on the shared FTP and uploading new versions regularly. Make sure the FTP has a clearly defined folder structure. Make sure naming conventions are used. Make sure that file versions are numbered and wherever possible previous iterations are archived just in case. Ideally make sure the entire FTP is replicated to at least one of your developer’s PCs regularly. Mods rarely recover from significant data loss.
- Set standards and stick to them – Make sure you establish standards early on. If you aren’t all working consistently, using the same naming conventions, scales and file storage locations, then when it comes to bring it all together you are likely to find things don’t fit. Suddenly items that were “finished” now need to go away and be reworked. This is turn has a ripple effect as they may then also need retexturing, animations may have to be corrected, code changes may require implementing, etc.
- Feedback is vital – All work should be shared with your fellow developers for critique and approval. Usually this is a formality, but sometimes bigger issues have been overlooked, or a fellow developer may have a subtle but welcome suggestion for improvement. So it’s best to do this frequently (better to catch a glaring mistake at the start than at the end). Ultimately your collective aim is to produce the best work you can. Unless the rest of the team agrees, you may need to rework something to bring it up to that standard. Getting everyone in the habit of quality assuring each other’s work is a way to ensure the quality is maintained.
Next time we will cover Tips 11-20 looking into the ongoing perils faced by a mod team as they approach and pass their first releases.
(to be continued…)

















5 comments
Nice post, there should also be a post about how you should follow your mod once it's released in the wild (public betas, first "gold" version).
In 2012, the population of people paying attention to mods is much smaller than in 2002 (both in proportion and in raw number), so you really need to make efforts into getting people to actually play it.
It means doing all the marketing stuff: organizing play sessions w/ interview with news/reviews websites, get some servers running (both in the US and in Europe, Australia if possible) 24/7, organizing frequent "fight night" to bring people together and so on.
The "golden era" of modding is long gone, you can't just expect common people to pick it up and turn it into a gigantic success.
What about Day Z then ? It's a mod, it's extremely successful now, and the devs had no marketing budget.
But it grew on the ArmA II community, who was mainly populated by older gamers who played a lot of mods when they were younger, and were already using several mods (ACE, ACRE, and so on) on a daily basis. This is a very specific kind of players, that you can't find (in large number) in "popular" games.
The SKS blog lost it's way in the Jungle ;)
We hope to have an update on it soon as it's being worked on.
Now where's that SKS blog again..? =)
Very good article, I have been in such mod team describe and all points are essential - so many great mod idea never come to fruition as some basic rules are dismissed. Thanks for sharing!
I wish most MOD teams would follow these simple yet effective steps when starting out, we would end up with more finished content rather than unfulfilled dreams, of which the MOD community is full of.