Quote from SenturaHalf-life: Source was bullshit, they're fixing it!
that's a feeble excuse.
No one needs an excuse to mod. You're not in it for the "glory" or the (non-existent) pay-check. You do it because you want to do it and you enjoy doing it. That's it. For the love of the game, art for art's sake, design for design's sake, etc.
That said, I think we should all follow the Adam Foster model: Periodic, self-contained, highly polished releases until Valve offers you a job.
Quote from CampaignjunkieHalf-life: Source was bullshit, they're fixing it!
that's a feeble excuse.
No one needs an excuse to mod. You're not in it for the "glory" or the (non-existent) pay-check. You do it because you want to do it and you enjoy doing it. That's it. For the love of the game, art for art's sake, design for design's sake, etc.
That said, I think we should all follow the Adam Foster model: Periodic, self-contained, highly polished releases until Valve offers you a job.
i never raised a question about whether or not you need an excuse to mod. i don't go into what people waste their time on; because frankly, i don't care. the excuse presented, however, is not an opinion of the mod team or whoever may be responsible, but rather just a way of displaying negative bias towards a mod/game.
it was uncalled for.
Quote from D3adshttp://www.moddb.com/mods/smod-crysisCan anyone say pointless?
Wow, it is a shame really. He has some very nice models (from what you can see from the grainy video at least) but really, why would you? Source will shit itself on most computers playing that since it is definately not made for it.
nothing wrong with it really, execpt that the talent of the people working on the mod could have a far better purpose imho.
but that's just my opinion, not theirs, obviously.
Quote from SenturaHalf-life: Source was bullshit, they're fixing it!
that's a feeble excuse.
This isn't an excuse. Their own aim is to recreate Half-life with better graphic as players expected it! They're doing the job well. This isn't only a remake this is an enhancement!
Quote from Seldoon182Half-life: Source was bullshit, they're fixing it!
btw, are they still working on it? I haven´t heard something about it for a long time now...
The most original mods fail because you either can't get a team behind you or they require to much work for people to do in their spare time.
The least original mods fail because they are crap ideas came up with by people who don't know anything about modding and just produce a single shitty concept drawing of a character and a two sentence plot.
So you gotta be somewhere in between.
Mod's, and game's in general, should just be fun. You can't expect everyone to make the the next dystopia, natural selection, or whatever. People have to work inside their capabilities, not everyone has groundbreaking ideas, and you aren't getting financial incentive to keep going. Even if you are making the same old City 17/HL2 style maps there is lots of room for creativity in goals/puzzles/enemy placement/level design/pathing/etc., without changing at all the basic core gameplay or idea of the game.
As Hourences mentioned, the management of mods that actually start to produce some nice work gets absolutely stupid. they are 100% convinced that without management and leads the mod will fail, is depressing.
Some mod teams even have NDA's to digitally sign to say your not going to screw around with it, I mean talk about going over the top. I kind of think of it like playing soldier as a kid.
5 Good friends can make a fantastic mod with no leads, NDA's or deadlines.
If I ever make another mod it will be with a small team of friends with a common goal. None of this pretending to be a professional studio mentality.
You guys maybe have some information about good management in mods?
Would be very helpfull in the future.
I hope that my ball mod gets really far, so I can push it as an example on how you are suppose to run a mod team without NDAs, 300 members, 300 leads, and a cooler website than mod...
Running a mod:
-No paperwork. No NDAs, no contracts. If someone wants to screw you they will anyhow, with or without a fancy self written NDA. No one will fly to the other end of the world to sue a 16 year old kid who did something uncool to a non profit project. Give me a break really. All paperwork will negatively impact mutual trust.
-Small team. You cannot manage 30 people, you really cant. With 30 people, you will get politics kicking in. It will prove to be difficult to keep everyone involved and up to date. As a leader, and presumably the most experienced dev (as if..), you will spend pretty much all your time on just talking to these 30 people, hampering your own dev work... 30 people is also wholly unneccy. If you need this many people to create your thing, your design is flawed. See next point
-Great and super efficient design. You cant make the next GTA game as a mod. You cant make a WOW clone as a mod. You cant make a mod with 30 playercharacters, 6 different environments and 29 levels, and 4 types of gameplay. You need to go for something that is doable. Im actually writing a book/article about this step at the moment.
-You need to go step by step, and create releases often to keep the team motivated, and proof to them that progress is made. Do not attempt to create the entire mod at once, go step by step. Work on core functionality first, make a working release, and then go onto the next step.
-People spend their time onto mods, for free, because they want something out of it. Identify what, and try to give them that to keep them interested. If they want neat pics for their portfolio, have them work on nice things (and not a bunch of barrels all the time). Take on dirty work yourself if you can to keep it fun for those who help you for free.
-Have just 1 lead. Too many leads and paperwork ends up in a bureaucracy, thats bad for the team. Too many leads also results in too many different visions, arguments following, and so on.
-You need a strong lead who will create the entire mod by himself if he must. This will also motivate the team in the sense that they know it will get finished for sure.
-You cant force teammembers to do exactly what you want them to do if you dont pay them, much too boring especially for artists and designers. Strike the balance between getting what you want, without taking their creativity and input away. Push them into a direction, but then let them handle the rest themselves.
-Mods cannot be run like companies, because people are not being paid. People who are not paid will accept a whole lot less crap than people who are. Your highest priority is to cut down on the amount of crap, and keep it as down the earth and basic as possible.
The last point is one of the reasons so many mod teams fall apart. And inexperience and lack of people of course.
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.
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 
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.
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.
That's a great list Hourences, I agree with everything you've said there. You should post that on the moddb forums or something 
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.
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.
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/
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.
Quote from SteppenwolfHourences 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.
Don’t have an account yet? Register yourself now and be a part of our community!
