Compliments of General Sun
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 Accuracy
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.
Realistic Expectations/Timeline/Prioritizing
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.
Soul Searching
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.
General Planning
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.
Organization 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.
Check-ins
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.
Check List
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.
The BlackList
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.
The WhiteList
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 Borrow Material
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.
Public Relations
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.
Release Model
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
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.
From Stalin Ghost:
Learn how to communicate well! It's essential that as the figure head of your mod you can talk to various individuals, whether fans, developers or other important community members in a coherant, intelligent way. It's no good expecting you can get away with "U's" and "2's"! Often this isn't a huge issue with some members, but many prefer to read information that reads well. It not only looks better, but people are more likely to support you if it looks like your mod is being lead by educated individuals.
It's also important you pick up "forum ettiquette". This means that you understand the basic conventions and manners common to forums. And don't just reserve this for your own mod's posts, but across the community. It's all part of presenting an image of intelligence and organisation.
I'm unsure as to where this one would fit inAnother helpful hint: Networking! Start talking to everyone who is "important" within the community, whether over IRC, MSN, AIM or anything like it. Getting to know such people can lead to new opportunities, such as new developers, ideas, or sharing of media/research.
Lusted RTW Specific Suggestions!
Know the game
Get to know the limitations of the engine and find out what is and isn't possible. There will never be full blown 3d naval battles in Rome - Total War, it just isn't possible, and there will never be planes. Learn about the hardcoded limits such as the 21 faction limit, and plan your mod around it. There may be lots of limits to what you can do, but there is still a lot that is possible with the engine. If you have the time one of the best ways to add new features is through scripting, though it is complicated to learn.
Start small become big
Start of small, whether your mod be realism or LOTR. Release a small version first, maybe custom battle only if you are changing the time period/setting, then add in a small campaign, then a bigger, with each version building on the last. Just look at the Rome Total Realism mod, it started of small but is now the most popular RTW mod out there.
Learn as much as you can yourself
As much of Rome - Total War modding is done through text files, you yourself can learn to mod a lot of this, so you can do more of the work yourself, and have a better idea of what else needs doing. A good way to learn is to join other mod teams, keep your own mod in the background for a bit whilst you learn the skills to make it as good it can be.
Links and Resources for Mod Teams http://generalscollective.com/ - My website, where this article was originally posted. It's a great resource for all modders. http://moddb.com A modification database, get yourself listed. http://www.xfire.com/ A great chat application.
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.