Results 1 to 15 of 15

Thread: What a mod leader should know

  1. #1
    imb39's Avatar Comes Rei Militaris
    Patrician Citizen Administrator Emeritus

    Join Date
    Sep 2004
    Posts
    20,866

    Default What a mod leader should know

    Posted on behalf of Halie Satanus - El Cid

    What a mod leader should know.

    Muizer
    Publius
    Professor420
    Lusted
    Makanyane
    Bwain
    Khelvan
    Dol Guldur


    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.




    Dol Guldur

    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
    Forth Age....


    Posted from the .Org with permission from DG.

    Last edited by Halie Satanus; October 03, 2007 at 04:41 PM.

  2. #2

    Default Re: What a mod leader should know

    I wrote a guide on this topic several months ago. It is featured in my tent.

    http://www.twcenter.net/forums/showthread.php?t=47115
    Clients: Caius Britannicus, Waitcu, Spurius, BrandonM, and Tsar Stephan.
    http://www.totalwardai.com

  3. #3
    Halie Satanus's Avatar Emperor of ice cream
    Join Date
    Nov 2005
    Location
    London
    Posts
    19,574
    Blog Entries
    1

    Default Re: What a mod leader should know

    Bump, just added (post#2) a great article by Dol Guldur from the .Org. Thanks to Dol for permission to post it here.

  4. #4
    Arbaces's Avatar Miles
    Join Date
    Jul 2005
    Location
    Călăraşi, Romania.
    Posts
    393

    Default Re: What a mod leader should know

    Hmm, nice work guys...

  5. #5
    WImPyTjeH's Avatar Wimpy of the Sore Ass
    Join Date
    Apr 2006
    Location
    Belgium
    Posts
    628

    Default Re: What a mod leader should know

    Have you guys seen this ?

    If you want to post it, you'll have to contact Palantir/MasterOfNone/Dol Guldur first :wink:


  6. #6
    makanyane's Avatar Content Director
    Patrician

    Join Date
    Feb 2006
    Posts
    8,323
    Blog Entries
    1

    Default Re: What a mod leader should know

    Would it be possible for someone with moderator powers in here to add index/bookmarks to top post? Prof420 has pointed out we should have something on this in Wiki, I'd like to eventually try and get someone to write a summary article with links to the individual bits of this - but can't link to sections at moment.

  7. #7
    Halie Satanus's Avatar Emperor of ice cream
    Join Date
    Nov 2005
    Location
    London
    Posts
    19,574
    Blog Entries
    1

    Default Re: What a mod leader should know

    Like that??

  8. #8

    Default Re: What a mod leader should know

    thanks guys, great

  9. #9

    Default Re: What a mod leader should know

    he copied the textes from others. Its not his work, he just sticked all together and said: Hey have a look at my awesome, brilliant, and big work! It was a big effort, but finally I did it!!! Yeah look at my great text! Its all written by me.
    ummm...LOL!?

  10. #10

    Default Re: What a mod leader should know

    You do realise that the intention was exactly to compile what some modders had said and that the poster made absolutely no attempt to present this as his work and he actually put the names of the authors in big, bold letters for everyone to see, right?

  11. #11
    Augustus Lucifer's Avatar Life = Like a beanstalk
    Patrician Citizen

    Join Date
    Aug 2006
    Location
    Mote of Dust
    Posts
    10,714

    Default Re: What a mod leader should know

    Quote Originally Posted by Aradan View Post
    You do realise that the intention was exactly to compile what some modders had said and that the poster made absolutely no attempt to present this as his work and he actually put the names of the authors in big, bold letters for everyone to see, right?
    Nonsense! We should hang Ian posthaste for this blasphemy, I will hear none of your dissent!

  12. #12

    Default Re: What a mod leader should know

    Here are a few tips:
    • Don't immediately assume the person who's currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn't got any closer to being released.
    • Game Coder is probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
    • The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of his or her life to this process.
    • The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship.

    Thanks for sharing this useful post.keep up posting.


    ____________________________
    SEO

  13. #13

    Default Re: What a mod leader should know

    Helped alot

  14. #14

    Default Re: What a mod leader should know

    rep+

  15. #15

    Default Re: What a mod leader should know

    Thank you for sharing , it's useful

Posting Permissions

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