Top 8 Reasons Why Mods Fail - WIP

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