. What a mod leader should know
Hi, If your reading this there is a good chance your thinking of starting up a mod or recruiting a mod team, i have asked some of Twc's resident and best modders (and a couple of great posts from the .Org) to give a small insight as to what can be involved in such a task.
Some are basic overviews and some are more specific but all have plenty of insider knowledge that we hope you will find useful as you enter the world of modding Total war games. Now reading these may turn you off as they may make modding seem a daunting task, but consider this, these guys were all just like you once and they wouldn't be still modding if it wasn't for the help and support of the community and the simple fact that modding is fun.
Halie Satanus .
Posts from the .Org posted with permission from the Authors.
Key Elements You Need to Start a Mod
1. Maps: Getting a working map is the most important part for your game. You cant play a mod unless the map itself loads. As such this should be an element of primary importance, but doesn't require you halt progress on other elements (like units, ui, etc). It is best to get your map working as soon as possible so you can refine and test it - theres a lot of code associated with a new map which means lots of mistakes are possible.
Some mods can get away without modellers (by simply doing reskins, gameplay fixes, etc.) So the key to this is
2. Modellers and Text Editors: knowing what your goals are. If you are planning a major conversion (such as a fantasy based mod, like LOTR) then make sure you have at least one or two full time modellers to help. As for editing files, it is nice if you can find someone you can do this but ultimately as mod leader you should be prepared to take the brunt of this burden, if necessary. Text editing requires no extra programs (just notepad) and the plethora of tutorials available make the only excuse for not knowing how to do this (if it is your task) laziness.
This is the icing on the cake. It is not needed to make a mod, but it is needed to help make a good mod. Immersion is key when you are trying to make in essence a new game for people to use, so things like loading screens, unit cards, faction icons, etc. will go a long way towards making your modification a stand out.
3. 2D artwork:
4. Organization and Leadership: Have a plan. Don't go into a project with little or no idea about what direction you want to take it, and how. Try to keep information on who has what tasks, and what tasks have already been completed, very easy to find so that you dont have people doing the same work. At times you may also have to ask mod members to work harder, faster, change something they have done, etc. This may not always be easy, as often these are your friends as well, but keep your advice here simple and constructive, and you should have few problems. Also, when people ask to join your mod, be very hesitant to say no to them. Even if they have no modding experience whatsoever - modding can be learned, but hard work and dedication cannot.
"So you want to make a mod, eh?"
Let me preface this article by saying, every single gamer on the entire planet has a great idea for a game, or a mod of their favourite game. Their ideas are always superior to all other ideas, and unique to all other ideas. And sometimes, they are. But the ingenuity of an idea, or the greatness of a concept, is irrelevant. What matters, as someone starting the mod, is YOU. YOU will run the mod, fuel it, push it, not the other way around. This is the first fundamental mistake people make. Ideas are worthless, and with few exceptions (Lord of the Rings, Star Wars, etc.,) no one will be as excited about your idea as you are, and you will get no talented recruits based on an idea alone. What matters, is YOU.
Are you able to start a successful mod? Likely not. Have you ever worked on a successful mod before? Have you ever led a mod? Do you currently possess all the skills required to complete your idea (art and coding)? These are vital questions that most people do not ask themselves when they start a mod. Because, honestly, its depressing. But they are questions that hold true, in example after example. Now, it will be very easy to ignore this advice. There is nothing to stop you from posting it anyway and looking for team members. So let me try to convince you why it is in your best interest to not start your glorious mod idea.
Is your idea REALLY that good? World War II/III? Comon. Deadly virus outbreak? Comon... Post-apocalypse? Warcraft? Generic fantasy? No matter how good, and how nuanced, your idea is, on the surface, it is extremely generic. ALL ideas are, there are very few 'original' ideas. And if you think yours is original, it is likely because you do not have enough experience as a designer. On the other hand, all ideas are unique. But the unique aspect is always second to the generic aspect, until you create something so people take more time to peer into your concept. Is your idea copyrighted? Is it based on Star Wards, Lord of the Rings, Wheel of Time, etc? I don't give a care to intellectual property infringement as far as mods/nonprofits go. But if you do not possess the skills to start a mod otherwise, what gives you the right to start a mod based on a pop-culture concept? Leave it to the experienced people to start the mod, then you can work on your favourite franchise, and learn, at the same time. Starting a mod based on these franchises takes zero skill, and even less originality. Just because you will automatically attract more talented people, does not mean the mod will be healthy. YOU will be its initial driving force, and if you aren't able to drive, you are going to steer the ship off course or crash it entirely. What will you do? Unless you are able to produce assets of production quality, or have a good amount of coding knowledge to implement the mod's important features, you don't serve a purpose. You hold no practical power or authority as the founder, as the leader, as the manager, "web-guy," or designer. I have met only a handful of skilled designers, and I have never met a designer that formed the team and led it. Design is an auxiliary role, and if designers are leaders, it is because they have inherited a team, are extremely skilled and respected at what they do, and the team has proven they can get things accomplished beyond design. Can you create a decent product if you are by yourself? For artists, this means, can you create enough art to push the mod past the starting line, and after that, most of the art for the entire mod? For coders, this means, can you set up the gameplay systems and features on your own, as the only coder? Things such as maps, sound, design, etc., are auxiliary, and do not create an entire mod in and of themselves. What do you have to gain from starting a mod? Are there any other mods similar to yours? Why not join one of these mods, to contribute to a product, develop your skills, and aid others? If your mod is "Dinosaurs vs. Smurfs," your concept is likely too unique to find another mod similar enough to be interested, but on the other hand, too unique to find anyone with a similar interest or passion to help you with the mod. As I said before, ideas mean nothing. If you can do the work, you can make people excited for your Dinosaur/Smurf game. If you had your dream skills, would you be content working at the whim, or even at the same level, as the former-you? Why would anyone who possesses great skills work for/under someone who lacks any real skills? Do not expect to find people much more talented than yourself. And do not expect them to work on your project. They will often naturally come along to 'pop culture' projects such as Star Wars or Lord of the Rings, but it is highly unlikely a skilled artist will sign up for a mod that has skins made in MSPaint. Finally: You need skills to make games. A lot of skills. Mad skillz. You are much better served spending your time learning and 'doing,' rather than struggling to create your own team. Then, once you've blossomed, you can start your own project will experience, confidence, and skills. If you lack the fortitude to invest the time required to build your skills, you will never be able to create your own mod. And I hope, after reading this, you won't think you can convince other people to make your mod for you.
How to Make a one man mod.
First off i must say this is the hardest way of making a major mod for TW, just because of the sheer amount of work involved. For minor mods it is easier as the amount of work is reduced.
Reasons to make a one man mod.
There are various reasons. The reason for me to make TE a one man mod was because i do not work very well in a team, and like to set my own deadlines for my work. For Alexandros, i worked mainly alone because no one else actually wanted to help it seems. But the main reason for both was because i wanted to make my mods. I was making them for myself first, and the community second. I was driven by the desire to play the finished mod. This was especially true, and it was a huge blow when i lost all the work on it and TE Gold due to computer probelms.
Learn to do as much as you can yourself
I started off as a unit editor, first text files, then 2d textures, then 3d models. But for TE i had to branch out into many different aspects of modding to get the work done, such as trait modding, faction editing, building editing, sprite making, adding in night battles, making recruitable generals and so on. This meant that when it came to Alexandros, i could doo most of the work myself, though there were some aspects of modding i could never grasp mapping, and so asked a mapper to help me out.
Make things easy for yourself
Use other peoples work if you can and they give you permission. Do not spend months on a new map if there is already a perfectly good one out there tht does what you want. Likewise with unit models and skins, most of those in TE are not done by me, and this helped move things on a lot quicker. Sometimes though you do want to have something in it that is yours, like i always had my Romans in TE, and for Alexandros i was determined to do most of the models and skins myself. But if you go down that road, get help if you need it. Countless times i've run into problems only for a modder i now to help me out.
Luckily there are a huge amount of tutorials and tools in the RTW mod community so thst anyone can learn how to do any aspect of modding.
Its your mod
Remember that what you are doing, you are making yourself. Listen to other peoples suggestions, but don't give in to what most people seem to want if you don't want to. Your maknig this for yourself remember.
I, for one, was pleasecd to see the sensible approach to modding that was adopted around conditions of use. I think, as a community, we handled it far better than most. It reflects the general sensibility of the people who come here, and a degree of maturity in the community that is a refreshing change to some...'other' areas if the wonderful world of forums!
Having a section of answers saves having a mass of 'sticky' threads and also takes the load of the search function...so often missed by those who need it most! You can just point a novice in that direction and let him find the answers as best they can, without having to trawl the depths of years of posts! All good.
It is also good to highlight some of the things that have caused mods to sink, both those that fizzled out some months after their start, or those that launched majestically off the slipway only to plough straight beneath the waves before the paint was even dry.... All too ogften, the same mistakes are made over and over, resulting in despair. We cvan, as a community, point people in roughly the right direction.... but they STILL need to be free to make their own mistakes.
Some good points here..plus some stuff that is just as unhelpful as no advice at all! Personally, I have been pretty much a team of one. My experiences reflect the way I like to work on things. I can model, skin, animate, text edit, make a map and generally...given enough time....can do all the tasks that a mod requires. I have had people join me to help..but these have been volunteers who approached me and who had something to give. All too many 'recruitment' threads attract a mass of volunteers to research or test..but not to model, skin, animate etc. By relying on myself, I am in control of the development and the direction. For me to hand that over, I would have to be sure the person I handed it to shared my vision of the finished product. This works for me....but would be a disaster for most teams!
I refrain from giving advice on this point because I know my advice would not bo good for most.
Modders / Members .... only time and invovlement can do this. A member gains value in the community by learning, sharing that knowledge ( not sitting on a grand breakthrough to give their mod an ego boost! ), and by involving themselves in what goes on.
Mod Packs ..... hmmm.... interesting!
A mod is what you want to make it. I released my Skeleton Horde as a simple replacement for the Gauls. Unit stats were virtually unchanged bar minor tweaks, and the thing was just a fun way of putting some new visual content into the game. That is a simple 'modellers' mod and anyone could do it that way. Release them as simple swaps that can run in both skirmish and full campaign battles and that works very well. I was going to do more with them...but people wanted to play with them, and this was a simple solution.
Metal Mayhem, however, cannot be handled that way. It can't be sliced up into 'packs' since it changes far too much to ever be balanced. I have already had to remove all the standard horse and camel models from the game to make room for the units I have added. New build trees, new everything! It either goes out as a finished product....or I keep it on my HD for my own fun and for the entertainment of my kids...who love it!
In all things, though, the MOST important thing for ANY mod is to really thoroughly scope out what you intend to do, and the volume of work you will have to do to complete it. Be 100% sure that you can do everything you plan to do, and DO NOT EVERassume you can 'solve that problem later on once the mod gets going' . Test the concept, and if it works carry on. If it doesn't...work around it or give up!
I tested my animations, tested my 'all horse' concept ( and had to include some bi-pedal robots for skirmish battles involving cities... it INSISTS you have a sapper or ladder etc. ) I knew all the things I had to do COULD be done, and that left me just with the challenge of making the content.
I PLANNED it , I TESTED my theories...and then I started my Mod. I have pages and pages of notes, sketches, diagrams etc. and I know what I want to get done. If every mod did the same, I think more would get done!
Posted from the .Org with permission.
I have to stress that there is no one right way or wrong way to organize and manage a team. This depends on the person and the team members, (and in a business setting, the organization at large).
In my experience, the more people are being compensated, the more they are willing to follow a single person's will. That compensation may be financial, for "real" jobs, or in the form of recognition, or even in the form of having their ideas used and valued, for non-paying jobs. Perhaps it is in seeing the realization of a purpose or cause, or end goal.
For modding I think that the more "power" that individuals have in a mod team, the more they feel valued, and the more engaged they are in doing their part. EB has never had a single brain at the top. We have had several "leaders," but not in the sense of creative control. Rather, we act as moderators, or very much like project managers in business whose subject matter experts are the people on the team. The manager just makes sure that all ideas are heard, that decisions are made efficiently, and that disputes are mediated.
Size matters - a big team is of course much more difficult to manage than a small team. However, ability and reliability are the primary factors in team size. There are times when a small number of people have a great deal of skill and dedication; these can be the core component of a team, and may be all that are needed to complete smaller mods. Or just one, for the smallest.
The numbers will likely have to increase as the size and complexity of the mod grows. Like business organizations, tasks will tend to become more specialized as the complexity (and team size) grows, and thus will need more management. Unlike someone said above, I think there is a place for many historians, if the mod is focused on history. But this has to be balanced with people who can do the work, in a mod where these tasks are broken out, otherwise lots of research will be done but the mod will never get going.
As a leader and/or the public face of a mod team, I can guarantee you that staying emotionally detached will be incredibly difficult. This is where I failed most as a "leader." Emotional attachment is sure to be high for all people on the team; there is no financial compensation, so people are dedicated for other reasons. As a public figure, you can't really afford to be engaged in this way, otherwise you will make poor decisions. For instance, I did not have a job for quite a long time, and dealt with a very serious medical condition, and I channeled my frustration and emotions into EB. This led me to state things emotionally in a way I would never do normally. Especially in a business environment, I would never have said things like that. Keeping your emotions in check is very important. This can lead to people leaving the mod, as well, and I guarantee it will if you get angry/snap at people easily.
A release schedule generally depends on the mod and the mod team. Here we consider individuals' goals. For instance, if one of the goals of the mod team is to be exposed to game companies so that the members can earn jobs in the industry, it is in their best interest to release only versions that could be considered polished. Likewise if the mod is hurting for members, the team has to do a very good job of keeping the fans involved, through distributing information, or through more quick releases. Releasing too quickly will be a problem in that case, though, as fans don't like to have to restart their campaigns often. It really depends on what your needs and goals are.
Finding some balance between introducing information to the public but not committing yourself to anything is very difficult. In general, if you care at all about pleasing the fans, never, ever, ever give a release date or make any promise of any kind at all. Even in the real software development industry where people are paid to do this work and can be held accountable by someone external to them release dates are often missed. Not missing the dates leads to great disappointment and even more heartache for all involved. Keep expectations low and you have a much greater chance of exceeding them and pleasing the fans.
However, keeping the fans involved is important to most mod teams. Regular information posts with teasers can help keep interest up. I am sure there must be some way to keep the fans informed, perhaps with some sort of constantly-updated post that contains percentages done for various areas of the mod toward the next release, but I don't know how to do it.
Potential members must be fully informed that if they can't meet whatever deliverables they are tasked with that they have to be able and willing to hand over the work they have done and keep everyone informed. In fact in a situation like this making sure team members' work is transparent is very important. Team members should keep the team updated at all times as to the status of their tasks. There should be no reason to hide what work is being done from the team.
I don't really have advice on how to make and stick with decisions. I guess this is just something that you learn through experience. There should always been room for improvement, but there is no need for endless debate about things where no new evidence is presented. Change control is important; you don't want the scope of the project to keep creeping, either.
Stay as light-hearted as possible. Learn what makes the team members happy, and try to give it to them. Make sure everyone stays civil. Jerks and people who are simply not nice to others do not make for a happy or productive team. The skill that they bring is not worth the problems with other people. Personality is important. Some people just do not play well with others.
Posted from the .Org with permission.
TOP NINE REASONS WHY MODS NEVER GET FINISHED
Unless you are a glutton for wasted time and effort you probably want to actually finish the mod you begin. This article is a practical (and quite opinionated) look at how to finish mods by planning in advance. Why such an article? If you are new to TW modding you may be unaware of all the forums, threads and even mod-specific web sites that have "died" over the past couple of years or more. Their numbers are testament to the failure of mod starters (modders or non-modders) to finish. One can only imagine what might have been achieved had things been done more wisely.
Before we get into what it takes to finish a mod we should probably say that there are different types of mod. Let's take a look at them first:
1. Enhancement Mods - these enhance the original (aka vanilla) game by improving or correcting certain aspects of it. This may range from tweaking the AI and correcting annoying bugs to full realism mods where much of the visual and textual elements may be improved and changed to reflect a more historically-accurate game. These can be some of the quickest mods to make, but the full realism ones may take almost as much effort and time as Full Conversions (see below) if the mod team are dedicated to detail.
2. Game-Era Mods - these are modifications which convert many aspects of the game into a period of history either similar to the vanilla or one which focuses on an area of the vanilla. These can vary in terms of time and effort but are generally the ones that tend to get completed a lot quicker than Full Conversions or the larger Realism mods.
3. Full Conversions - these endeavour to totally change every or nearly every aspect of the game, not in terms of enhancement but in terms of total change. They are sometimes called Total Conversions. They take the vanilla game engine and seek to create a world very different from the era of the original game. Such conversions may be based on known sci-fi or fantasy worlds, mythology or just from original imagination. These kinds of mods need to be most carefully thought about in the planning stage because they will eat up a lot of time and effort to complete.
This article applies least to the more narrow of the enhancement mods, and most to the full conversion - but I think all modders and would-be modders can benefit from it (I hope). I'm going to use the example of the Fourth Age mod because (a) Middle-earth is a world that most people are basically familiar with compared to other fantasy/sci-fi worlds, (b) it falls into the total conversion category and (c) I am personally familiar with the history of that mod and so can share examples of things we did right and things we did wrong...
Now, as to those reasons why most mods sink into the sea of oblivion...
REASON #1: SETTING SIGHTS TOO HIGH
Unless you've been seriously modding the Total War engine for at least a year you probably have little idea about how long things take and what's involved. It's not just a case of the obvious: research, code, model and create artwork. There's also testing, balancing, mod and forum management, dealing with feedback and tech. support, installers, tools, and a whole host of other issues that are not maybe so obvious when you start or want to start a mod. An don't assume that fans and "the public" will flock to support you in practical terms. Most just want the mod to play. They won't want to learn new skills or be involved in tedious tasks such as thorough beta testing. Your team will likely have to do all the most important work even in that regard. Make sure there is someone on your team - or at least advising your team - who has experience about how long things take. This is critical.
The Fourth Age probably wasted almost a year because of our initial unawareness of such things.
REASON #2: IMMATURE TEAM MEMBERS
Someone once said that character can be defined by following through on your decisions once the emotion of making them has passed. We've all committed to things we've then given up on - no one's perfect. But completing a mod will need to see a good few members on your development team who are of a maturity that will not give up after a few weeks or months. I suspect that most mods that languish and pull through do so becuase they have more mature members in their make-up. It is not entirely bound to age of course, though by and large the older members will be more mature in this regard.
REASON #3: A MODDING TEAM WITH NO UNITY
Every member of your team should understand that they will have commitments for a couple of years, and for at least 5 hours per week (managers more). Mod teams must be cohesive and working hard is a good way of achieving that. Those who do not put in the time and effort will drag down those who do and these former should be removed (or not hired in the first place) and put in an outsource or support capacity. Members who are lazy or who have very limited time can even frustrate some modders enough to leave the team - and that is just not worth it. This happened to us at least twice at the Fourth Age and each time we lost good modders. It is often the best modders (who tend to have the higher temperament ) that get affected by the laziness (real or imagined) of others on the team.
Of course, many can help as outsource support such as voice actors, concept artists, composers, LOD makers, etc. Some may be freelancers. The principle is - whether outsource or team member - that a person's circumstances should be known and their commitment made and completed every week. As long as people abide by their commitments things usually go smoothly.
Now at the Fourth Age we do not accept new members onto the team off the bat. We put them in Outsource support and if, after a few months, they prove diligent and constant we take them onto the team. Past experience has shown us that the majority of people who join a mod team off the bat (with no trial period) leave after about a week. It's true that many don't complete the trial period but a core committed team of 4 is going to work better than a core committed team of 4 with 4 others doing little.
REASON #4: TAKING ON MEMBERS THAT REQUIRE TOO MUCH WORK TO NURTURE
Some would-be modders are of the opinion that they can only be a good modder if they have a personal mentor. Sometimes we even see people launch mod ideas and plans and then announce that they have no modding skills! Generally they do not read tutorials or get very confused if they do try to follow them. My advice is to avoid such individuals and get them to help out in a way that suits their acumen. They will waste a lot of your time if your try to help them. Modders, imho, need to be self-educated and have initiative. Sure, a lot can be learned from discussion on modding forums with other modders but the real learning comes from our own volition.
Be cautious of those who want to help but say they have no modding skills but are willing to learn - why did they not learn an aspect of modding first if they are so interested in helping? There are plenty of good tutorials to become a good anc/trait coder, a good tech-tree coder, a good texturer, a good modeller, a good audio coder, a good 2D artist, a LODer, a mapper, ad. inf!
REASON #5: NO RELEASES
Morale in a mod team (and among those who support the mod) will be best secured by making sure you have some releases. A year without any release is going to see morale plummet and team members leave. Your first release might be a custom battle to showcase your work, maybe a historical battle too. See Reason #6 for more advice on how to make sure releases are forthcoming.
REASON #6: FAILURE TO PLAN
I've mentioned this here because it deserves special attention though it certainly overlaps with Reason #5 and Reason #1.
When the Fourth Age firmed up its ideas back in September/October 2004 (just a few weeks before I joined) it decided upon setting the mod in the entirety of the map found in the LoTR novels. And there was no limit I remember as to the culture/faction slots which were to be used. When it dawned on us that we could not have two very different factions in the same culture slot (because of shared portraits etc.) we adjusted downwards but it was not until December 05 that a decision was made (after some weeks of discussion as to the viability of finishing 14 (I think) factions and the entire map) to focus on a part of the map and get that completed first.
So much more could have been achieved if we had come to this decision a year before. My advice here is more for full-conversion mods but I think it is very important. The principle is simply to identify the smallest self-contained and playable area of the mod you would ideally *like* to complete and then work on that area as if it was the entirety of the mod.
This is what we did with Corsair Invasion and got it done in 11 months (estimated 3000 hours of work). For a TW mod I would advise the following:
* select 5 factions that can fit into no more than 3 cultures
* select an area of your map of no more than 50 regions
* If possible, select cultures that most nearly approach vanilla cultures
* focus only on modding units, code and the strat map (don't worry about battlemap buildings/settlement plans)
This may not seem like much but it will probably still take you a year if you intend to make a good job of it.
Once it is complete you may reassess your goals and team strength and decide to quit or to do something different or to add more to the campaign to work towards your original 'big picture' mod.
REASON #7: BAD ORGANIZATION
Bad organization on a mod team ends up with very buggy releases (if any releases at all). Why? Well, let's look at how an organized team would work...
Each member, when they complete their assignment, should (after approval of the design or art director) pass it along to the Build Manager (the person who maintains the whole build of the mod). They should have tested it (if possible) before handing it over. The Build Manager can then add and test it in the full build. A Build Manager must be intimately aware of the files and be a good bug tracker and squasher. Coders need to make sure they do not overwrite the work of others and so it is important that if a file needs to be changed in order for a coder to get something in his area of files to work then he *not* make the change but get the person maintaining that file to make it (though the Build Manager will often be that person).
On the Fourth Age we have 4 coders - an audio coder (whose work is quite independent of other files), a trait and ancillary coder, a map coder and the one who does everything else who is also the Build Manager. If the Map Manager wanted to change the name of a settlement, or the tech-tree coder (the Build Manager in this case) the name of a building this might affect the coding of the anc/trait coder who may reference that settlement name or building in their code. So the map manager/tecth-tree coder does *not* alter the anc/traits files but informs the trait/anc coder of the change or submits his code to the Build Manager with a note that files not under his jurisdiction need changing. The Build Manager may be the one maintaining those specific files at that time or it may be the assigned coder.
Not keeping track of such things is bound to cause loss of work (by one coder overwriting the work of another or rendering the work of another unuseable because changes cannot be identified) or - potentially even worse - create bugs!
Of course, the best releases will have some bugs in them and probably even fatal ones. There's a lot that can go wrong. But being very caerful in coding and testing almost everything as it is coded will greatly reduce the occurence of crashes. Don't code a page of coding and then test - it may take you a lot longer to track down the cause of a CTD than it would have done to code in smaller steps, testing after each. Some files are very sensitive, even a missing space or comma can cause a CTD with no error message to help!
When things get too buggy it can cause members of your team and players to lose interest. And on a side point, don't release buggy betas. All releases should have a basic team-tested integrity regarding fatal errors.
REASON #8: NO MODDERS ON THE TEAM
Historical/milieu research, nice concept art, nice visuals, nice music...all of these are not worth much unless you have some good strong skilled modders onboard. Map makers, unit builders, tech-tree coders, 'traiters', game mechanics researchers, code researchers, etc. - these are the ones who produce the glue to bind everything together so that it is in the right place and firmly held. This is where the bulk of the modding time will be in any mod. This is where the frustration and energy will circulate. Better to have these guys with you and doing some of the graphics and research than a whole bunch of historical experts or designers with imaginations that have no concept of hardcoding.
Many people have offered their services to the Fourth Age, claiming that although they do not know how to mod they have read the LoTR books - we're grateful for their support but that stuff has been long-since covered and, besides, the existing team is made up of members who have all read the books (some of us quite a few times!).
Don't launch mods with no modders!
REASON #9 : UNFOCUSED TEAM MEMBERS
Unless team members stay focused and pay attention errors will creep in. If someone on your team does not even know which of your modded factions match up with the vanilla internal faction names then you probably ought to downgrade them to outsource. Your team need to be on the same page - not in a different book or even in an entirely different scriptorium altogether
This article is posted here for comment and improvement. It is written as I thought it and has not been revised; and indeed is in much need of it.
Posted from the .Org with permission from DG.
General Guide to Mod Development Management
Nowadays, making modifications to games are easier, and far more prevalent than ever in video game history. Modifications can be small, they can be big. They cover all genres, from Role Playing Games, to Strategy Games, First Person Shooters, Sports Games, Adventure, etc.
Making modifications has changed from a pseudo legal activity not so long ago, to something that is now a very lucrative opportunity, making mod development a very attractive venture. Many mod developers has hit it big, the traditional reward is a job offer from a gaming company. Now however, many mods are going retail, with the full support of the parent game. To cite some examples, Red Orchestra, Day of Defeat, and Counter-Strike.
In the shadow of those scores of mods that succeed are the hundreds that fail. Why? They do not apply some very simple organizational skills. The important items listed below are not common sense, but tried and true business and organizational tactics. They are very easy to apply and once you read them, youíll be slapping your head and saying Ėof course. And now without further ado:
Planning/Knowing Your Mod
Key to mod development of course is planning. Making a video game is like writing a book, you must know the ending before you can begin. But in a more general sense, the leader must know the mod. If you are doing a mod based on an intellectual property, or historical event, ask yourself the question, how important is accuracy to IP or history important to me? If the answer is very, then act accordingly, if the answer is not very, then you will have much greater freedom once the development process begins.
What are you trying to achieve?
Ask yourself what you are trying to achieve in making this mod. Tell a compelling story? Make a political statement? Change the gameplay in a new and innovative way? Simply provide a new gaming environment? As a small bit of advice, if your choice is the last one, then it is usually not enough for a good game. A modification that is similar to the original game in gameplay but with rehashed graphics usually does not go well in a community.
New Intellectual Property
If your world is completely new, then make sure you know your world. Make up a believable back-story. Give history, politics, know the layout of the land before you begin.
Plan realistically, what can you achieve. Most games go out of ďstyleĒ in 3-4 years, most games get a sequel in that time. Know that this is the limit on development time. So what can you achieve in that time? This question goes hand in hand with what you are trying to achieve. If gameplay is the most important thing, then coding, modeling and animations are usually what should be done first, and the rest of the art can wait. If telling a compelling story is your reason for creating the mod, then the writing, texturing, modeling, and map design needs to get into shape first.
To do this effectively all the best mod leaders use a timeline. You must let your team know when you expect each item to be complete. The organization section has more tips to help you prod your team members through each item on the timeline, but in itself the timeline is an invaluable tool.
Like doing homework, starting a big project when the end seems so far away is not a good way to proceed. You are more than likely to lose interest midway. Divide up the project into doable chunks and productivity will soar.
Ask yourself the question, why do you want to make this mod? If your answer is, just because itís a cool idea that hasnít been done yet, give up. You are not motivated enough. If your answer is, because I want to turn this mod into a retail game and start a gaming company, then youíre onto something. Make sure that is a realistic goal, and work towards it. If your answer is, I make mods for personal enjoyment, ask yourself the next question, will I still be enjoying making this mod two months from now? How about in six months? A year? Two? If you are certain that your answer is yes, then prepare to embark on a grand adventure. Itíll involve lack of sleep, lack of a social life, a hunched back, and thick glasses.
It should go without saying that you need to plan as much as you can. You must be able to mentally play your mod from Point A Ė Z. It is OK if you skip some letters in between, but you must hit all the key points.
Creating Your Team
Accept everyone who applies, whatever their experience. Every contribution has the potential to be useful eventually. This does not mean include every contribution that is made. A crappy model is still a crappy model, and itís your job as leader to not include it into the mod. But less experienced members can be taught, and in time grow to be very valuable.
Organizing Your Team
Productivity is wasted when the team isnít well organized. The best teams can be quite large, with as many as 40 developers. There are two ways to organize the team, depending on the mod that you are working on. One is by Specialization. The other is by Content. If you choose to organize by Specialization, then the team would have an art department (with modelers, texture makers, animators), a coding department, a beta-testing department, a research department (if you are worried about accuracy to history or IP), a mapping department, and whatever else you need.
The other organizational model is via Content. One part of the team would do Europe, another focus on Africa, another would focus on Asia. Or, one department would develop levels 1-3, another 4-6. Or, one department work on early game, another mid game, and another end game. You get the idea.
The choice of organization of course depends on the mod in question. Can your mod be easily split up into different content areas? How big your team? Do you want all the content to release at once, or some parts first. All these factor into deciding on the organization model of your team.
Also important is for each department to have a leader. This is someone that the team leader can communicate with easily, make sure (s)he is in your time zone, has a compatible Instant Messaging chat system, and have good leadership and communications skills. It goes without saying that this person must also be extremely dedicated. Skill in their department shouldnít be that big of a factor, as the job of the leader can be more important than simply doing a texture.
Once development begins, it is very crucial for all members to check in periodically. A way to do this might be to create a thread in team forum for each department. Then all the members would post their work weekly. It is a simple way to keep track of productivity and progress. A compilation of all finished works could result from each weekís check in.
Each department needs to have a checklist. This goes hand in hand with the timeline. Each item on the check list needs to be prioritized, and each member assigned (or call dibs on), an item. When it is complete, the item is checked off, and the member could move onto the next item. Something simple to keep members focused and the mod organized.
This is the list of low productivity members. This list can be public or private, available to only the mod leaders, or to all of the team members as an incentive to work harder. Developers on the BlackList are used for the odd jobs, things that are not critically important to the main goal, but helpful to be done. If these things ever get done, great. If not, itís not a big loss. Having a BlackList is helpful in prioritizing things to be done and getting those most important done first.
On the opposite side of the fence is the WhiteList. This can be a list of high productivity members to help encourage people, or simply everyone whoís not in the BlackList. But like the BlackList, it is important to have when dealing with volunteer team members.
During the Development Process
The mod development world is similar to the open source world in many ways. Things can often be reused from game to game. If youíre modding a 3D game, then any 3D mod has content that you can use. Any model can be ported from game to game, any textures. An ogre model made for Unreal Tournament can probably be used for Elder Scrolls. The same is true with textures, sounds, written materials, much other multimedia. Of course getting the proper permissions is very necessary, but in my experience, mod developers are usually more than generous with these things.
Donít worry too much about it. The mod will speak for itself. But that being said, good PR can be helpful in certain situations. It can gain the mod more members, and motivate current members by generating hype. The downside is huge expectations that the team will feel compelled to meet. But then again, that might not be a downside.
Here are a few tips generate good public relations.
Get listed in as many modification directories as you can. A good one is moddb.com
Have a pretty website. First impressions can be everything and oftentimes your website is the first impression. Stay away from: Frames, Tables, phpNUKE. Do use, Flash, flashy screenshots, good sound effects.
Have a catchy slogan. If Lenin taught us anything, itís that slogans are the key to winning over hearts and minds. Peace, Land, and Bread runs much better with people than a treatise on the advantages of Marxism.
Email everyone who in media. Get in touch with gamespot, gamespy, ign, 1up, PCGamer, the New York Times technology editor. If your mod has something to show, then chances are good that youíll get some kind of coverage.
Be active in your game community. Be a part of the community for your parent game, be there.
Regulate what your members say. Team members who gets into argument with fans are not good for PR. Tell your team members, donít say anything that might potentially create an internet scandal.
Get a community sponsor. Make friends in the community, and get a sponsor. A sponsor is someone on a big community forum with a huge post count. Preferably a moderator or an administrator of some sorts. He can help you get the word about your mod out.
Get your fans involved. Go for community tournaments, a score based ladder with rewards for winners.
Trumpet news with big fanfare. Never do a quiet release. Send out rounds of emails every time something happens, keep the fans hyped up.
Decide on your release model, will you launch your mod through its various incarnations, alphas, betas, then numbered versions, or will you do a big release all at once. While the first impression of a mod is important, releasing by bits is usually the safer approach. For most mods it is recommended.
To me the smartest release model is the following. Like software, do a first initial alpha version. Then slowly add more features to it as material comes in from your various departments. Do many releases, even one every week or two. At a certain point, leave the Alpha/Beta moniker and call it a Release Candidate. The Release Candidate should be feature complete for this version. Half of the team should switch to work on more features, while the other half focus on perfecting the current version (balancing, bug killing, adding in more detail, etc). When the current version is perfected, then the whole team converges again on the next version.
Let the Team Do Their Job
Donít try to control everything. As team leader, your organizational tasks will eat up a lot of your time, and trying to dictate specifics is futile and can be counter-productive. Let your team use their imagination, products coming from multiple people can often be more creative than something thatís fed out of one person. Unless something seriously doesnít fit into your game world, let your members make the mod how they want it. While your contribution is crucial, it is important to let the members feel that they are actually contributing as well, not just working as your extra hands and feet. Pass this message onto your department leaders as well.
Beta-Testing can be a painful process. I very much discourage using in house beta-testers. They are just another branch of your team to organize and yell at, and are often less effective than just regular players. The ideal situation is in the release model described above.
A tip in beta-testing might be to use a CVS. What is a CVS? It is a web based system to keep track of bugs and development. Most open source and many none open source application developers use a CVS, Iím a little surprised at its relative small rate of adoption in the mod community. To find out more about CVS, Google it.
Be a Good Leader
This should go without saying, but here are some small tips anyway.
Be nice to everyone, when people slack off, put them on the BlackList, donít yell at them.
Give credit where credit is due.
Be generous with compliments, they donít cost you anything, and can make a world of difference to the person receiving it.
Be sparing with apologies for small things. It really sucks when you screw up, and if you can, cover it up. Others often wonít make a big deal out of it if you donít.
When you really screw up, apologize your brains out. When it is a big deal, make sure you acknowledge it.
Be liberal with emoticons. These little smileys are great. They can take the sting out of a rebuke, and be used to show pleasure. When the leader is happy, everyone else is too.
If you feel that you are lacking in this department, then go onto Amazon and buy a book on the subject, rarely can a poor leader lead a mod team successfully.
Links and Resources for Mod Teams
http://moddb.com A modification database, get yourself listed.
http://www.xfire.com/ A great chat application.
http://www.pjirc.com/ A great webbased chat application. Install it on your website!