Originality in mods

[Nysuatro]

Very interesting. Thanks Hourences

And what about submissions of external artists ?

I got the idea from a project of the game-artist site.

Like, searching for an artist who want to make just one thing for the mod.

Kinda like freelance, but not paid.

[2d-chris]

That list should go on Moddb, it's exactly the same as I would write

Although, INS was opposite on most of those and managed to get released and be a big hit. There are always exceptions to rules though

[Hourences]

Yes there exceptions, and it also just comes down to the people of course, but usually you want to get rid of all the bullshit. Im sure INS would have been just as great without the paper stuff and similar. That doesn't make the mod.

External artist can work, but you need to be careful not to have too many different styles and techniques going on.

[Steppenwolf]

Its true that it often was the opposite for INS but it only worked because we had a exceptional experienced team for mod standarts. But even then we had to learn a couple of things the hard way. If we had known the things we learned before we could have released 2 years earlier or so.

I fully agree with most of the points however. Not so sure about the point about paper work. If we talk about NDA ok. But if this includes design documents, schedules and stuff like that i would have to disagree.

I also disagree with the point about team size. Imo you can't hire enough people for a mod because 80% of them will do no work anyway or quit after a couple of weeks. You will only find out who is valuable for your mod if you give a lot of people the chance to join your team. For INS we often had 50 or so members but the core team stayed always the same ~12-15 people.

And i would add one more point to the list:

As a leader don't be mister nice guy to everybody all the time. You are the one in charge. You have to make decissions and you cant make everybody agree with them so don't even try. It's a waste of time. Kick slackers and people who play manipulative mind games rigorously. They only cause harm to the mod and the team spirit no matter how talented they are.

[D3ads]

That's a great list Hourences, I agree with everything you've said there. You should post that on the moddb forums or something

[Hourences]

Sure design documents can be ok, if they are limited. What is simply wrong is writing design docs just to write design docs because "studios do it like that too!!!111". Do you really need a lot of text? I mean, really? If you build the mod up step by step, like I am doing with The Ball, by releasing a new version every ~4 months, each twice the size of the previous version, you don't need to have a lot of design documents. You know exactly what you will focus on for this release, and since it is a small step up from the previous release, it doesnt has that many new features that it warrants long and complex design documents. A simple forum post explaining what will be done would suffice already.

Also everyone will know in what direction to think and what to base themselves on because they can take the previous release as the example. You don't need a bunch of documents that describe every godforsaken little detail. That also takes the fun out of modding and that is exactly not what you wish to do, especially not when dealing with volunteers.

Same for schedules. If the releases you are going for are small, it is not hard to keep track of what has to happen. Do you really need a schedule? All you need is "Alpha that day, beta that day, release that day" and you're set... Each member can figure it out for themself how to pull that off. Dont make things overly complicated or annoying!

Also about teamsize. It actually works the other way around. You are better off with a small but highly active team, than a small core group surrounded by 40 slackers. That doesnt motivate people to do anything - "but those 29 others do nothing too". It becomes acceptable to slack. A small team raises motivation and thus productivity, and keeps things focussed. If I am uncertain someone will not commit entirely, I simply do not let them join. They may be able to help out, but they will go into the category Additional Help. They can still prove me wrong later, and I would have them join for real if they do, but nothing is worse for the team spirit than an announcement every week "yeah we got a new guy", and then 3 weeks later he disappears again, only to be followed by yet another announcement "yeah we got another new guy because we need to give everyone a chance".. If someone would leave and join Grin every week, it wouldnt help your motivation.

[D3ads]

Surely that depends on whether it's a single-player mod or a multiplayer mod? A multiplayer mod is much managable there in the sense that you can release new versions for people to try periodically and get feedback and if any changes are needed there's the paperwork there. For a single-player mod, you need to make a design document discussing the different elements of the project, otherwise you're telling the members what you want to do/need to do and then expecting them to remember everything and take it on board. I made a design document recently that discussed things for TF in relatively deep form but didn't discuss every last thing in full detail. I think that's a fine line there, just writing out the things they need to know in brief without going into too much depth except when it comes to discussing storyline and character analysis.

[Hourences]

My mod is SP, we have no design document and we release in episodes to keep it easy. I worked on two other very large SP mods before. Neither had design documents. Works just fine. Again, if you are going for small releases, there is just not a lot to say. The first release of my mod was made by 3 people, with 3 people you can just chat with each other. Then, when you double up for the next release, you take in more people (we took in 2 more), and they can take your first release as example. Aka they can just play it, instead of reading about it. They only need to read about the new features and that isn't all that much really. Continue like that, step by step. Increase the team a little bit after each release, to ensure a gentle and stable growth (!), and bump up the team spirit. Take only those in you really need for the upcoming release, and no one else.

Long article about mod creation btw: http://www.rockpapershotgun.com/2008/09 ... -an-idiot/

[Steppenwolf]

Hourences i respect your opinion but what works for one team doesn't work for another team and your way of doing things is not the universal truth for perfect modding. I had the luck of working on two released and succesfull mods for a long time. My experiences are just different ones.

For example the lack of proper design documents was nearly the downfall of both these projects.

If i would ever start to work on a mod again i would make sure that it gets a proper design document and a well organized plan for the coding. You waste so much ressources when people don't know _exactly_ to the detail what they are supposed to do. The coders will prioritize on the wrong things or will code stuff that is unnecessary, the level designers will create map layouts that don't work etc.

In the long run this will demotivate the team more then some "professionalism".

And don't forget that many people are virtualy unable to come up with something if you don't give them exact directions. I met many artists like that. Not everybody is a designer or inventor. Many just want to improove on their skills and need someone who tells them what to do. In the modding community where you meet many inexperienced people this might even be more common then in professional games development.

One last comment about the team size:

In modding you usualy don't get the luxury to pick cherrys. Especialy small teams have problems to find staff at all. They don't even have to bother with the question if 30 people is too much or too less. You can develop your mod with 5 people, thats fine. But as i said for other mods it doesn't work. We couldn't have done Insurgency with a team of that size. There are other (released) mods especially for Battlefield 2 who will tell you the same.

And as i said you have to kick slackers. We always did this at Ins. Our core team at least always worked their asses off. Same can be said about the mod that i worked on before which had a size of around 25 people.

[Minos]

Hourences i respect your opinion but what works for one team doesn't work for another team and your way of doing things is not the universal truth for perfect modding. I had the luck of working on two released and succesfull mods for a long time. My experiences are just different ones.

For example the lack of proper design documents was nearly the downfall of both these projects.

If i would ever start to work on a mod again i would make sure that it gets a proper design document and a well organized plan for the coding. You waste so much ressources when people don't know _exactly_ to the detail what they are supposed to do. The coders will prioritize on the wrong things or will code stuff that is unnecessary, the level designers will create map layouts that don't work etc.

In the long run this will demotivate the team more then some "professionalism".

I totally agree with this. Organization can never be bad.

If I was to start a new mod nowadays I'd gather 3 different people to start with, one experienced in coding, other in art and and another one in game design. We'd sit down and discuss what we want to achieve with our project and what our longterm goals would be. We would write basic design docs, code skeleton, conventions, rules, define the art direction etc... Once everything is established and we are sure about what direction to take we would start recruiting a few people, preferably people we know and trust. These people would form our core team. This way the mod team could grow around these few people making organization easier and making it clear to everyone what their role is.

Hourences, what you are saying is basically gather a few friends, discuss some ideas and let everyone do whatever they like. This method can work on super small mods when you have a team of veterans, but I'm pretty sure it won't work when you are dealing with less experienced people. We never had a design doc in Insurgency and that caused us to scrap countless maps and waste hours and hours on needless tasks.

I do agree with releasing the mod in smaller cycles though. It's easier to keep focus when you have a rough idea of when things should be done and what features need to be worked on for each release.

The biggest mistake mods can commit however, is too much exposure as it takes the focus away. You get more concerned about polishing your work so it looks good on magazines/screenshots than working on the core gameplay. We were a lot less mature in Insurgency back then, and we know how too much exposure is bad. We lost precious hours dealing with mod drama and shit like that. I hate it when the first thing mod teams create is an empty webpage. You shouldn't build your mod an webpage until you have a fully functional beta and any gameplay to show. Any mod can show pretty screenshots, but only a few succeed in having good gameplay. In the long run nobody will care about eye candy as technology grows and games consequently look outdated. A good gameplay can never get old though and that's the key to longterm success in my opinion. That's why people still play Quake 3, CS 1.6 and Fallout, despite those games being 10 years old.

[Hourences]

Yes the mods urge for publicity is horrible. Most spend more time on their websites than on the mod. Dont create a website until you got a mod...

I worked on about five or so mods now, 3 of them singleplay. All of them very succesfull. All of them released. None of them ever had any kind of design document what so ever. We just talked to each other, which works just as well really.

The coders will prioritize on the wrong things or will code stuff that is unnecessary

As the leader I just talk to the guy, and I tell him what has the highest prio. Problem fixed?

the level designers will create map layouts that don't work etc.

Talk to them more? Maybe they started off building layouts too soon? Core gameplay not finalized etc. That is why you need to do small builds all the time, so the previous release can be taken as example. You dont need a lot of design doc for this? Just a working build?

And don't forget that many people are virtualy unable to come up with something if you don't give them exact directions. I met many artists like that. Not everybody is a designer or inventor. Many just want to improove on their skills and need someone who tells them what to do. In the modding community where you meet many inexperienced people this might even be more common then in professional games development.

Yes, but there are also many that do wish to have some say in what is going on. There are of course A LOT of people who do want to be guided, and I am not saying you cant guide them some more. It is a case by case thing. Talk to them more if you think they need some more help. Forcing everyone to stick to your design doc is a too general approach.

And as i said you have to kick slackers. We always did this at Ins. Our core team at least always worked their asses off. Same can be said about the mod that i worked on before which had a size of around 25 people.

I agree that they must be kicked, but, if you hire a new guy every week, and kick a guy every week, again, I would leave the mod myself because it would give me a really wrong signal. You would get very nervous and demotivated if people are kicked all the time...

Hourences i respect your opinion but what works for one team doesn't work for another team and your way of doing things is not the universal truth for perfect modding. I had the luck of working on two released and succesfull mods for a long time. My experiences are just different ones.

Of course nothing works for everything, but surely there must be some way that usually, on average, works better than other approaches. There are mods made by 1 guy. There are mods made by 147 people teams. Everything goes, but somewhere in between, there is this holy number. I am not saying my five is that number, but surely there is some approach that will give you most chance of success with the least possible troubles? That is what I am saying. It is not about what works (everything can), but what gives you most chance on succeeding... And considering that, it is logical that smaller teams are easier to manage than large teams. That is a fact. So my point is, if you know that you will make it twice as difficult to manage the mod by increasing the team size, then dont, or only get super experience people who do the work of five others, or, hold of until you REALLY need all of these people. Small team = gets you spend more time on development, less on team managment <- that was my point.

Hourences, what you are saying is basically gather a few friends, discuss some ideas and let everyone do whatever they like. This method can work on super small mods when you have a team of veterans, but I'm pretty sure it won't work when you are dealing with less experienced people. We never had a design doc in Insurgency and that caused us to scrap countless maps and waste hours and hours on needless tasks.

I dont think you can look at the design doc as your holy grail. I am sure that the lack of design doc didnt help you in INS dev, but the reason why it didnt work is prolly more complicated than just "yeah we had no design doc"? A different approach on team management, work order, the peoples experience levels, and so on prolly also had a big impact on it. Did the INS team made fully working builds every month? If not, wouldnt that have helped for the maps? Youd get to test them in the game right away, without trying to guess how it would play by reading a design doc?

In general: Organization is good when it is self organizing. Forcing organization is bad. Your goal as a leader is to make it self organizing, not to force everyone to do what you want. Guide people. Do not force people. Especially not when they spend all their free time on your dream!

[Steppenwolf]

I think the reason our opinions are different is because each of us has only the experience with a specific size of mod teams. We are both right in our field of expertise.

When you reach a certain team size you get to the point where you can't just communicate your ideas to each and every team member verbally all the time. You need it black on white for them. Thats the main lesson that we have learned with Insurgency. You cant run a team of that size as a group of friends. It needs to be semi-professional just for the sake of not falling apart alone. Doesn't mean you can't have fun or friends within the team. Look i bet you have fun at your work, which is completely professional. I do for my part.

If you ever write a book or article about it talk to Jeremy. He was the leader of Red Orchestra and Insurgency. If anyone on this planet knows about the challenges and difficulties of leading a big mod to success then its him.

There is another thing you can take in consideration. Big mods like Insurgency or some of the BF2 mods are not just for fun for the developers. Many members see them as steps in their career and in fact they have proofed to be. Thats a big difference to smaller "fun" mods. A little professionalism really doesn't hurt or bother anyone on such a mod. In fact it prepares them and teaches them some valuable stuff for their later professional carreer.

[R_Yell]

I'd say the complexity and originality will dictate how much documentation a project needs. Even for a solo mod, the amount of people is secondary to me, having a design doc shouldn't be downplayed. I'd say one the reasons for constant failures in modding scene is such lack of prevision, some people due experience or mental skills may succeed working without a good design doc, but in the end is a recipe for fail.

[Taylor]

Seriously .. the great thing about mods is that you don't have any constrains so you can be as creative as you want, especially considering that you do it for yourself. I'm not sure at all, because i was young and i changed a lot since then, but i remember that in 1998 - 2004, when modding was great, people had a lot more original concepts than what the modding community of nowadays is doing (with the exception of some gems of course).

What do you think guys, do the old modding community was more creative, or is it basically the same thing ? because i actually can't answer to this question myself

Well, even compared to the generic clones, nobody played the quirky mods.

People are also looking at mods different now than they did back then. Creators see mods as a passage into the industry, they want to work on the Next Big Thing. Gamers see mods as products that rival commerical games in quality.

[Psy]

I completely agree with what Taylor said. There seems to be this general idea that mods have to be of the same quality as a game developed by a professional studio in order to be successful or for it to be worth a download.