| Home Page | Recent Changes | Preferences

Making Mods/Mod Death

Why do Mods and Mod Teams die ?

Many Mod Teams die before they publish something. Some die before they have had a chance to advertise their existence. If a team exists without a purpose its members will most likely leave and find other teams. Some mod teams collapse before they really start because the idea was either hard, vague, or the team couldn't agree.

Mods that die before they start

The majority of mods that die before they start, start in the same way. The "project manager" makes a post on a forum advertising a "great new mod idea, come and help me work on it.". After a bit of digging prospective team members find that the only thing that exists for the mod is simply a website. If you've been there and done that, or, are thinking about doing it then read Mychaeel/Mod Startups. It will save you some pain.

Occasionally a mod will die before it's been started because it is so ambitious. Most "total conversions" go this way. It's very easy to come up with a mod idea where the actual amount of effort required to build it is so daunting that the mod team goes into a type of paralysis. The mod itself is so big that it's scary.

Mods that die before publishing anything

I would say that the vast majority of mods involving a team of two or more people fall into this category. Work on the mod starts off well, but when the "interesting" work is completed the members of the team lose interest and gradually drift away. Maintaining a tight focus when all that is needed is polishing work on the user interface, the config, testing, and bug fixing is difficult. This is made harder by the distributed nature of most mod teams.

Lack of organisation or even over organisation can also kill a mod that has started well. It generally exhibits itself as a gradual decline of interest and an increase in a poor attitude. Some team leads try to be the focal point of all communication. This can help, but more often than not prevents the team gelling properly.

Interruptions from "real life" and a decline in interest in the mod from team members also kill mods before they publish. Loss of a key team member to real life problems can be catastrophic for small teams, especially if the person dropping out has become the central focus of the mod. If the mod is a reasonable size then it's very easy to simply get sick of working on it. One the "mod sickness" kicks in the only thing that will keep a team together and working on the mod is stubborness, the desire to actually finish something, and an enthusiastic beta-testing team.

Some mods die because one particular member of the team "goes to the dark side" and becomes increasingly negative and cynical about the mod – or constantly attempts to further their own agenda over and above everyone elses. Once that happens the whole team can be quickly sucked into an increasing attitude of negativity. Unfortunately the only way to avoid destruction in this way is to kick the "bad apple" from the team.

Making a sizeable mod is not for the faint hearted. There is always far more work to do than it first appears. This in itself is a discouraging factor that will cause mod teams to falter and stumble.

Other reasons mods die

Some mods start with a great blaze of publicity designed to send ripples of amazement and interest throught the community. This is all well and good (although over hyping your mod is a bad thing) but when the community doesn't even bother to look at the mod web site (assuming there is one) it can be very discouraging. This discouragement can in turn lead to the mod team giving up on the mod and either finding something else to do, or disbanding.

There is an inherent risk with any mod idea that it simply doesn't work when implemented. This might be because of a technology limitation or simply an interface or implementation problem. Whatever the reason is, some great ideas just don't translate well into code. When a team finds themselves in this position it's very easy to point the finger at the person who dreamt up the original idea and blame them. In fact, this is the very worst thing you can do. These things happen - it's a fact of life. Rather than sit around being glum, or destructing the team, brainstorm another idea - or see if there is a solution to the issue you have. You've already got some experience working together and you've managed to get further than most.

If a mod does't get a detailed specification or description fairly quickly after its inception the odds are it will die shortly after. It could be that the idea itself is not interesting enough for anyone to want to add detail to it. Alternatively, the original idea could be so vague that it meant all things to all people, sparking off long winded and destructive discussions on what form the mod should take.

Handling a Mod Team Failure

Seeing a mod fail, or a team simply rip itself apart, is never a pleasant experience. For the people directly involved it can be a painful nightmare. And a very painful process. There are many ways of coping with this, good and bad. Rather than discuss in great detail each point I've summarised them. It's easier that way.

  • Don't ever post any personal attacks on team members on any forum anywhere – even if you feel like it. You might need to work with these people again. It's also a very childish and unhelpful way to behave. Even if the mod failure wasn't "your fault" you stand to lose a lot of respect from your peers. The Internet can be a very unforgiving place and has a long memory. Would you want someone on your team with a record of publishing personal attacks?
  • If you are still interested in continuing the development of the mod then get permission from the team and either finish it alone, or build another team.
  • See if you can work out exactly what went wrong. Once you've done that, come back and update these pages (avoiding mentioning any names). That way other people will benefit from your experience. And you have a record for future reference which will help you avoid it next time.
  • Quitting the mod scene altogether is always an option. However, this should be a final resort.
  • Taking a short break from mod making can be a good idea. It allows you a bit of a break from "having" to deliver.
  • Build some really really small mods. If you've been working on a large mod project for ages, and it suddenly goes awry, build some small mods and release them. A small mod is something that can be built in a couple of days (or less). Releasing a bunch of small mods is a good way to bouy yourself back up.
  • Take a look around for similar mods you might be interested in. Some of these might need some additional help even if they have no published vacancies.
  • Don't take your mods too seriously. I realise that a lot of people see mods as a way of getting into the games industry. Although this is "a good thing" you are better off making mods for fun first, and for career second. It's additional pressure you don't need and makes surviving a mod failure easier.
  • Realize that even if you are trying to use your mod as resume fodder, you will probably not get paid for it, and most people outside the community will probably not care. Remember where your priorities lie.

EntropicLqd: I've taken the liberty of resetting the discussion – hope no-one minds. Death Angyl - your comments have formed the basis of a new page Making Mods/Why Are You Making A Mod. Good work.

TSOShadow: It would be nice if someone slipped in a "Mod revival from the dead" Bit as I'm working on this in real life. (Unless I do it before I see a change then I'll go ahead and slip in what I did in the re-incarnation)

The Unreal Engine Documentation Site

Wiki Community

Topic Categories

Image Uploads

Random Page

Recent Changes

Offline Wiki

Unreal Engine

Console Commands

Terminology

FAQs

Help Desk

Mapping Topics

Mapping Lessons

UnrealEd Interface

UnrealScript Topics

UnrealScript Lessons

Making Mods

Class Tree

Modeling Topics

Chongqing Page

Log In