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.
How You Can Successfully Create and FINISH Your Own Total War Mod (aka MasterOfNone's/Dol Guldur's/Palantir's Retirement Rant)
I shouldn't let it affect me. But it does. The waste, the lost work, the broken dreams. Well, I'm retiring and so I thought I'd share a few parting comments...
I've been modding Total War games since the end of 2004. I have seen the announcement of many mods for Rome Total War, its expansions and the more recent Medieval II Total War & Kingdoms. I have not worked out the stats, but I think it's fair to say that very few of even the hosted mods actually make it to completion. After a while one can tell, almost as soon as a mod is announced, whether it will make it or not. I've been wrong of course, but not very often.
I should like to say that there will always be exceptions to the "rules" I mention below, but they are few and far between. In reading this you'd be wise to consider yourself unexceptional I say this because, with a lot of effort and time, mods that I would have said had no chance of ever being fully finished and stable were or are being actually completed - though I can think of just two as I write.
Why do some mods fail while others succeed? I hope to share some thoughts on this here, but before I do that you might be wondering what gives me the expertise to write such an article? Well, let me briefly outline my work in the realm of TW modding:
* Late 04 - Mid 2005 : Heavily involved in research, map design, general design as well as learning coding on the Fourth Age dev. team.
* Mid 2005 - End 2007 : Heavily involved in game mechanics/coding research as well as acting as Coding Manager and Build Manager for FATW. The last year or so of my tenure with FATW I kept the mod going and alive virtually alone due to the real-life issues and health of other members. Also learned many new skills - in fact just about everything about modding TW except for 3D work.
During the latter part of 2007 and into 2008 I released the following modifications:
* FATW - The New Shadow 2.0b (BI 1.6) - consistent winner of favorite fantasy mod & the only TW mod in the Top 100 on Moddb.com in 2007 awards. Featured in PCGamer (UK) Total PCGaming magazine and a best-selling German magazine
* The Multi-Mod Sampler (with Makanyane) (RTW 1.5) - this later made it onto the PC Gamer (UK) coverdisc for March 2008 and then again in February 2009
* The Dwarven Blunderbuss (RTW 1.5) - well, it's good to have some fun sometimes
* Gods & Fighting Men (Alexander) - featured on StrategyInformer as the mod for Alexander
* Title of Liberty (BI 1.6)
* Viking Invasion II (BI 1.6) - Main article feature in the Downloader section of PCGamer (UK), February 2009.
I also have worked on some other projects along the way such as modfoldering Europa Barbarorum for its fully-modfoldered 1.0 release, and the porting of Fourth Age Total War - The New Shadow (2.3 at the time I believe) from BI to the RTW engine (updated to the latest patch and released by Aradan).
I have written several guides and tutorials such as the oft-used Complete EDB Guide and the tutorial on setting up a seventh culture. And during my time with FATW discovered such things as:
* multiple building upgrades
* multiple bodyguards
* faction-specific building descriptions
* use of type in addition to class for mount bonuses in EDU
* use of temple and hinterland prefixes to adjust nature of buildings
* porting RTW/BI victory conditions
* the seventh culture slot
* negative upgrades (now used by FATW, EB, VI2 and other mods to effect reforms, block peasant armies etc.)
So, that said, let's begin!
1. Setting Yourself Up Mentally
OK, you love a certain Total War game and you think "Wouldn't it be nice to see a mod of [insert historical period/movie/book here]!" Now STOP and take a reality check. Let's do a quick survey:
a. Will the basic game mechanics lend itself to your mod? (spaceships are just a no-no in TW games thus far!)
b. Will the basic game assets lend itself to your mod? (building architecture, vegetation, etc. - if not, then you are probably looking at a full conversion of 3-4 years and even that will be a struggle)
c. Are you willing to learn at least 80% of what needs to be done modding-wise?
d. Are you willing to complete the mod on your own if need be?
e. Do you have enough time for at least one year to dedicate to finishing the mod? (50 hours per week for a year, or 25 hours per week for two years is a rough guide for a modest one-man mod - unless you are very familiar with the files and modding TW games); this amounts to well over a thousand hours even for a small mod.
f. Are you willing to work through "real life" despite interruptions by illness, PC woes, moving house, exams...?
g. Are you willing to rethink and downscale your ideas - to make your dreams realistic ones?
Can you answer "Yes!" to all the above? If so, you're in with a chance.
At this point I would like to put forward the very great wisdom in joining another mod development team rather than starting your own off the bat. This will give you experience and, equally as important, a sense of how difficult things are and how long they take. You might well find that you prefer to support mod development than lead it. You might even freelance between several mods as some so successfully do. Whatever the case, you need to explore and experience these things so that you can know what is best for you. Few, in my honest opinion, have what it takes to pull off - or lead - a mod.
2. Suggestions for Quick Releases
You might be sitting there thinking that it's OK to wait a year or two (or more) before a release. Game popularity aside, there are several reasons for getting a release (not necessarily the final one) out swiftly. The first is that it will bolster your (and your team's - if you have one) motivation. Second, it will stir up interest in the mod publicly and this will also boost your enthusiasm. As a rule of thumb no mod should allow more than 6 months to pass without some form of substantial release. If your mod is proceeding with the vigour it needs to have in order to be completed then you should have no problem with this time frame. A release can also give you valuable feedback to improve the next release and pick out any bugs. Just a tip here: do not release anything that has known CTDs. Resolve them first. You will not make a good impression with your fans.
SUGGESTION 1: Stop Trying To Take On The World
This is the number one reason why so many mods fail imho. They bite off more than they can chew. It has a number of negative effects. Firstly the enthusiasm hits a wall of gloom when, several months down the road, it is realized that what has been planned is going to take a lot longer, and a lot more effort, than originally envisioned. Often tons of research is done, ideas are discussed and even a map and units made - but when the buzz is over the dedicated modder or modders begin to discover they have set out a blueprint for a sprawling metropolis when they only have the resources for a village. As it dawns upon them that most of their work to this point will never be realized, this brings even more misery to that once-enthused would-be modder.
So how can this be overcome? Firstly, when fans and posters keep asking for various features to be implemented - or their own part of the world included - generally ignore them It's your mod. You must decide. Do not pander to expansionists - and that includes those on your team, if you have one! The spirit of expansionism is one of the number one killers of mods.
Mods will differ, but as a rule of thumb take the smallest scenario you can with your chosen milieu whilst keeping it playable and interesting. Some of the add-ons for M2TW are quite good examples of this. After all, they are only mods after a fashion. The Britannia Campaign focuses on a small part of the map (essentially the British Isles) with five factions and uses much of the original (M2TW) files. The Americas Campaign, on the other hand, though also having just a few factions and a narrow geography would involve a full-conversion of culture - text, 3D, 2D and audio - which would be a huge endeavour and not something for beginners.
Remember that you can add to or expand this idea if you wish and release a series of "modules" much as The Fourth Age has done over the past couple of years or so. RTR has also more recently employed this method with its release of The Iberian Conflict.
In order to solidify this idea into your head, let me go through my thinking when I suggested that FATW forget about going for the all-or-nothing approach to a campaign release. FATW began its life in terms of discussion around August 2004. By mid 2005 the full map and many units were completed. But we were overwhelmed with all the less-obvious stuff. We hit reality. Motivation was declining. Staff, which had numbered around 20 at our peak (with about a half dozen core members), were diminishing.
We needed to make a decision. Finish up something fast or run the risk of the mod dying. It was impossible to finish the campaign we had set out to make. It was just not realistic at that point. So we decided on cutting out about a third of the map and using just five factions, all of them "Mannish" and in harmony with much of the base vanilla architecture etc. Corsair Invasion was released in November 2006. If we had not done this I do not think we would have survived imho. Since then of course we have built upon that with Forth Eorlingas and then The New Shadow.
So, to summarize: narrow down your scenario (50 regions or less is good), keep close to vanilla assets in terms of culture, minimize factions (2-5 I would suggest).
SUGGESTION 2: Don't Reinvent The Wheel
It's almost humourous to see various mod forums of today and of yesteryear that essentially have the same subject but all of which have researched for themselves. Now, independent research is good but unless historical accuracy is a main feature of your mod you can probably use some of that already-posted work at least as a starting point. In this regard be careful that historians, researchers and others who may be working on your mod do not become fastidious. They will slow down the mod's progression. As the mod leader you set the pace and make the decisions, not historians. Obviously a mod dedicated to historical realism above all else will give more leeway for historians but there are few such mods that have this single focus.
If I could turn back the hands of time I would have pushed for a merger, or at least a greater sharing of resources, between FATW, METW and LOTRTW. We did some sharing of course but were unaware of the travails ahead back when we started. This brings up two important points:
Firstly, if you want to create a mod about (say) early Medieval Japan then look to see if a mod about that place and time exists already before announcing your own. Join them, help them. Put aside the need to be a "mod leader" (it's long hours and you'll have no social life ) for a while at least and see if you can work together.
Secondly, share your resources and help other modders. By so doing they will repay in kind. For example, in Gods & Fighting Men I used Arthurian Total War's map of Ireland as a base for my map, as well as several of their unit models. Most modders will allow this as long as they are credited of course. Never use anything without permission. You'll get a bad name and that will not make getting permission any easier! Vanilla and open-source assets can also be used or tweaked to greatly enhance a mod. It's amazing what you get if you just ask. And of course there are others who have resources that you can use, with permission such as musicians. After hearing "The Blood of Cu Chulainn" (theme track from Boondock Saints movie) I really wanted it for Gods & Fighting Men and so I made some enquiries which ended up with me on the phone to Hollywood speaking to the composers, Jeff & Mychael Danna!
There's a great tendency to want everything to be fresh and new - and all of your own making. Well, that's not a bad thing in some respects but keep to reality. Don't make new stuff just for the sake of it. Use the resources out there wisely - many mods will create stuff and then the mod will die, so much that is made never sees the light of day unless one of the team has the presence of mind to release the resource files publicly before disappearing.
SUGGESTION 3: Learn By Example
It's interesting that many quality mods that are released all share one thing in common - very dedicated skilled modders! Whether it be a large team or a team of two or just one, they get things done and done well.
I thought, at this point, I might share an example of how the very popular Viking Invasion II played out in terms of modding...
I'd been toying around with the idea of bringing MTW: Viking Invasion to RTW for a long time, but it was not until May 2008 that I started seriously thinking about finding the time to do it (I was thinking of fully retiring but this project idea kept me awake). I PM'd DaVinci (head of Chivalry TW) about it and he was very enthusiastic about the era and project. Likewise with Antagonist. Agraes (Arthurian TW) allowed me to use their base map and also - along with Chivalry - the units.
I then spent June and July working on adapting the map and all the units. I became unemployed in or towards the end of June and so was able to spend a great deal of time to get it done fast. Around August the second layer of the mod began - the stuff that many mods do not get to. I had help with various elements but most especially the traits, ancillaries and unit cards. Aradan also attended to the unit balance. Then, finally, I had help with campaign balance from Aradan and polish from the likes of Halie and others with menu-related 2D graphics.
So how did this mod get done in 113 days? Let's look up some of the reasons:
1. Use of pre-existing resources - maps and unit models do *not* (despite what some think) constitute the majority of what a full-conversion mod is made up of; however, the use of these resources from Chivalry and Arthurian and AoVaF saved some months of work!
2. Unemployment - OK, you do not need to be unemployed to make a mod but it helps to have a lot of free time. In July/August I was able to dedicate nearly all my time, for 6 days a week at least, to VI2. This fast-tracked it considerably. Serious modding can take up a lot of time. When I was working on FATW I had a 3-day part-time job and worked on the mod for three solid days and as many late evenings as I could, averaging around 60 hours per week, sometimes I hit 90 hours. Over the course of a few years this adds up into the thousands. Remember that this included lore research (though mostly not after the first 6 months), writing, designing, making tutorials, coding, testing, "pioneering" work, 2D artwork, filling in lots of big Excel spreadsheets, and a host of other minutiae....and, no, it didn't include playing beyond testing, I never played FATW seriously until Aradan came along and lightened my load and took over.
3. Help - If you help others (whether it be directly or indirectly - such as through tutorials) - then you are more likely to be helped. This is a great thing that benefits one and all. Halie ploughed in with tweaks to unit models, superb loading screens, banners, symbols and other miscellaneous menu graphics such as the title words and faction maps. Uranos did the unit cards and the Scandinvian part of the map. Aradan did the sprites, unit balance, traits, campaign balance, help with conversion of MTW:VI vanilla elements to a format for use in BI, and the tweaks and improvements in the subsequent patches. Antagonist drew up the basic unit rosters and wrote the unit descriptions.
3. Other Things To Avoid
As well as avoiding "expansionism" also avoid complicating things. There's a layer of modding that need not be attended to until the basics are done. If you avoid the temptation to start polishing the windows before the house is built, so to speak, you might end up with a playable (if unpolished) mod should real life strike (and it usually does at some point). Traits, sprites, ancs, scripts, LOD sets, music, battlemap buildings, balance are all things that can be put aside in preference to the basics: unit build, tech trees, map, units, cards, text, 2D art, symbols, baners, menu, etc. These can be attended to next, when all is stable. This method also helps track down bugs more easily.
Avoid bad coding. A mod should be coded so that if your coder were to drop dead or, worse, join another mod team (just kidding!), anyone taking over should be able to easily take it up where the last coder left it. This is facilitated by prefixing new files such as models and textures (FATW uses 4a_ for example), and using plenty of headers and comments in the coding text files. Use conventions in filenames etc. You might decide for example that something like modabbrev_factionname_category_unitname might be a good name (e.g. 4a_harad_inf_corsair). This also makes it SOOOO much easier to track down bugs caused by bad coding, both in the coding and filenames attached to the same. It also aids a great deal if you stick with the vanilla names in terms of association as much as you can, otherwise confusion can easily crop up and - if intuitive - you will not need to continually be referencing a checklist to see which internal faction name matches up with your new faction etc. This can save a ton of time in my experience.
Avoid taking time off. Generally mod leaders or other key members of a development team who take time off generally lose momentum or even stop doing any modding at all. To get a mod done you need to keep pushing unceasingly until it is done. Most modders who have completed quality mods will tell you they had to sacrifice sleep and socializing. Accept that as part of what it takes to complete a mod.
Avoid working on more than one mod at a time. I tried working on 2 mods at the same time once but gave up. Unless you are an outsource or a freelancer in a particular area of modding, you really need to focus on your own mod. This is especially true for a mod leader and the builder/coding manager. Unlike freelancers or those who add some of the more specific things to mods, a builder/mod leader needs to glue it all together, to build it all from ground up and comprehend and see all the interactions and methods employed. This often makes him the best debugger too.
Avoid losing the vision. You must keep in your mind the final goal and let it drive your non-expansionist enthusiasm Think about the specific aim you want for the mod or module you are working on. For example, in Viking Invasion II I wanted to portray and bring to life the old MTW:VI on a new 3D engine. I did not take my eye off that. I did not succumb to those who wanted to add more landmass, more factions, 100% historical accuracy, etc. Now, I did add a little enhancement (extra Viking faction, few more regions in Ireland etc.) but these were for gameplay and balance reasons chiefly.
So there you have it. Some parting words. Be enthusiastic but be realistic. Look at other mods, see what they have done and how long it took them. Help others but be willing to learn and do most things yourself.
Let me close with a poem I adulterated..er, I mean penned..
If you can keep your dev team when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can code and not be tired by coding,
Or, being lied about, don't deal in lies,
Or, being hated, don't give way to hating,
And yet don't look too good, nor talk too wise;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts your aim;
If you can meet with triumph and disaster
And treat those two imposters just the same;
If you can bear to see the mod idea you've spoken
Twisted by noobs to make a trap for fools,
Or watch the things you gave your mod be broken,
And stoop and build 'em up with wornout tools;
If you can make one heap of all your coding
And risk it on one turn of pitch-and-toss,
And lose, and start again at your beginning
And never breath a word about your loss;
If you can force your heart and nerve and sinew
To serve your mod long after it is released,
And so hold on when there is nothing in you
Except the Will which says "the mod is not deceased!"
If you can talk on forums and keep your virtue,
Or walk with modding legends - nor lose the common touch;
If neither fans nor forum trolls can hurt you;
If all players count with you, but none too much;
If you can fill the unforgiving minute
With sixty seconds' worth of an AI run -
Yours is the Earth and everything that's in it,
And - which is more - you'll be a Modder my son!