Results 1 to 1 of 1

Thread: Compiled Total War Eras Information

  1. #1

    Default Compiled Total War Eras Information

    Compiled Total War Eras Information

    Index:



    Preamble to Posting
    Compliments of MasterOfNone
    I'm not a moderator but I a modder. Can those posting please refrain from making post titles by the name of "I have a question" and various variants of the same. It is clear that you have a question by virtue of posting in the "Ask an expert" subforum.

    Also please make the titles specific. Modders scan through more than TWC modding forums and are very busy. They are much more likely to respond if they see a question in an area in which they are very experienced. A non-specific subject title to your post probably often results in your actual post never even being viewed.

    My rant is over.


    Total War Roundups



    Modding Tools and Resources
    Modding Tools & Resources

    Catalogue Description:

    This Catalogue has one of the greatest tutorials, guides, modding tools etc. ever made for the Total War modding community. If you are a modder or want to become one, go no further.


    Modding Tools

    Modding Guides

    Map/Starting Conditions

    Units and Buildings

    Text

    Aesthetics

    Miscellaneous

    Tutorials & Walkthroughs

    Other Compilations of Tutorials




    The Total War World
    Catalogue Description:

    This catalogue provides you with a multitude of links to various AARs and strategy guides made for the Medieval Total War and Rome Total War games. From extensive battlefield guides to informative strategy guides, this catalouge has it all.


    Medieval: Total War

    After Action Reports


    Battlefield Strategy Guides


    Strategy Guides


    Medieval: Total War - Viking Invasion

    Strategy Guides


    Rome: Total War

    After Action Reports

    Battlefield Strategy Guides


    Strategy Guides


    Rome: Total War - Barbarian Invasion

    Strategy Guides



    Medieval II Total War

    After Action Reports



    Strategy Guides



    What a Mod Leader Should Know
    Introduction

    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.

    Good luck.

    Halie Satanus .

    Posts from the .Org posted with permission from the Authors.



    Muizer.

    Mapping.

    1) before engaging a mapper it would be preferable if at least a rough sketch exists of the map layout including:
    - the area it will cover
    - an idea of what a regions map would look like.

    this is necessary because:

    2) you need to confer with the mapper about size and resolution of the map

    3) the mapper should then set up the template for the map, freezing the resolution for the rest of the project. Map extents are less critical and be reduced afterwards.

    4) On the template will be drawn the main geographical features (coastlines, rivers, mountain ridges)

    5) the template is then returned to the team to work out in detail the scenario (the "human geography"). Region boundaries can be painted on the template with any paint program.

    6) the filled in template is returned to the mapper who uses it to make a regions map and thus complete a basic map set. The minimum set of files that need to be modified are:

    text files:
    descr_regions.txt
    descr_region_and_settlement_name_lookup.txt
    imperial_campaign_regions_and_settlement_names.txt
    descr_strat.txt
    descr_win_conditions.txt
    descr_mercenaries.txt
    descr_terrain.txt

    tga files
    map_climates.tga
    map_features.tga
    map_ground_types.tga
    map_heights.tga (map_heights.hgt is the 32bit version)
    map_regions.tga
    map_trade_routes.tga

    These will be stripped of all information not crucial to getting the game on-screen. That is basically where the task of the mapper ends until:

    7) troubleshooting of the map during play testing.

    A mapper will generally know how to place resources on the map, buildings in cities, set up family trees, defining armies, characters, diplomatic stances etcetera, but cannot as such be expected to be creative or knowledgeable in this regard.

    Of course I'm heavily biased towards working on physical rather than human geography. I bet others work differently, but unless they say so we'll never know.

    Muizer




    Publius

    The Scriptorium's Modding Catalogue is a good place to reference. In regards to unpacking, I will shamelessly self promote and link you to this tutorial.

    Key Elements You Need to Start a Mod

    1. Tools and Utilities:
    -3dsmax: Currently the only program which allows you model for the Rome Total War engine via Vercingetorix' cas importer/exporter. (Note: This is not freeware)
    -GIMP: Freeware 2d graphic editor. With dds plug in you can use this to skin. You can alter virtually any 2d element in the game with this program.
    -DDS Converter 2: Useful for viewing skins if you are trying to find them. I find little practical use for it outside of that, but still handy to have.
    -XPAK: To unpack models, ui, and a lot of other game files you will need this.
    -XIDX: To unpack animations you will need this.

    2. 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.

    3. Modellers and Text Editors:
    Some mods can get away without modellers (by simply doing reskins, gameplay fixes, etc.) So the key to this is 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.

    4. 2D artwork:
    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.

    5. 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.

    Peace,
    Publius.





    Professor420

    "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.


    Professor420


    Lusted

    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.

    Lusted




    Makanyane

    TEXT EDITING Ė (WHAT A NEW MOD LEADER SHOULD KNOWÖ)

    Text editing is the rather unglamorous side of modding but it is essential (and also unfortunately the area most prone to producing CTD bugs!)
    Once everyone has admired the nice looking units / new map etc., what will keep users playing a mod is whether or not the game play is to their liking. Except for map geometry and scale, all aspects that affect faction balancing and AI behaviour are controlled by the text files.

    As mod leader if youíre not heavily involved in either the modelling / skinning or map making aspects then your team is likely to expect you to take on at least some of the text editing. Even if you are going to be otherwise occupied it would still be useful to have a good grasp of the text files and what can / cannot be done with them, before you attempt to recruit a team. If you havenít modded before I would therefore recommend making small alterations to a vanilla campaign to familiarise yourself with the files. It would also be helpful to have some understanding of the scale of the tasks involved before trying to assign them to volunteers. (Try adding one region / unit and multiply time taken by number required in game Ė then allow for testing / balancing etc.)

    Below is a very simplified overview of the files / areas involved for certain types of mods.

    MAP ONLY MODS
    Using all existing units but on a new map e.g. a new larger map or one that just covers Italy / Greece etc. (Off topic but important first make sure you / your map maker can actually get the land shape you envisage to load at the scale of map you want Ė as there are limitations on that! )

    There are other text files involved in making map load but main ones for optimisation are descr_regions.txt and descr_strat.txt:
    Descr_regions.txt has a base farming level that controls growth rate for each region (effects balancing), default faction and rebel type for each region and hidden resources (which can be used to alter recruitment etc and hence links to export_descr_buildings) - plus also starting religion settings in BI.
    Descr_strat.txt has amongst other things visible resources Ė they effect trade levels for each region (and are rather time consuming to place!) Each factions, starting regions, diplomacy settings, starting money, family tree and the position / make up of armies, and starting character traits are set in this file. Each regionsí faction_creator, initial population and pre-built buildings are also defined here.

    Small changes to any / all of these settings can make a large difference to how hard or easy a faction is to play and how well the AI controlled factions expand initially.

    UNIT ONLY MODS
    Youíre using an existing map but have decided to have Smurfs instead of Romans etc..

    To get new units into game you need to add them to at least the following: export_descr_unit.txt (all unit statistics and balancing), descr_model_battle.txt, export_descr_unit_enums.txt, export_units.txt (descriptions), export_descr_buildings.txt (to make them recruitable), descr_strat (to put them in at start).

    Also depending on what type of unit they are possibly descr_character.txt, descr_sm_factions.txt, descr_mount.txt, descr_rebel_factions.txt, descr_mercenaries.txt and (Iíve probably missed some) To add lots of new units youíll also have to amend many of the above files to remove existing units to make space within the hard coded limits.

    You may also need to consider alterations to descr_formations_ai.txt, to get the battle performance you want.

    FULL CONVERSION
    Work required for a full conversion can probably expand exponentially to fill any amount of time that can conceivably be allotted to it!

    All of the above areas are involved plus most if not all of the following: General expanded text editing for faction names etc. Addition of new buildings and /or building descriptions. Alterations / additions to religions (for BI). Alterations to cultures (and possibly inclusion of an additional culture) Traits and ancillaries (probably an area that could have infinite amount of refinements). Scripting if used (another area which could be expanded almost indefinitely). Editing to get in new features such as sounds / terrain etc. Alterations to names of leaders, quotes and events etc Ė so Ďimmersioní is maintainedÖ..

    Iíve probably missed some but that should give some idea of the possible workload just on the text side!

    Makanyane



    Bwain

    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.

    Lessons:
    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!

    Bwain

    Posted from the .Org with permission.




    Khelvan

    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.

    Khelvan .
    Europa Barbarorum.

    Posted from the .Org with permission.



    Guide to Mod Development Management
    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 Mods Never Get Finished
    Dol Guldur/MasterOfNone/Palantir

    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.

    Dol Guldur
    Fourth Age....


    Posted from the .Org with permission from DG.




    Stop Trying To Get On The World
    Dol Guldur/MasterOfNone/Palantir

    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!

    NOT Rudyard Kipling





    Assorted Links

    Last edited by Aradan; February 07, 2009 at 11:10 AM.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •