Bonnes équipes de modding

From Valve Developer Community
Jump to: navigation, search
English Русский

Cette page parle des équipes de mod qui sont comme elles sont, et qui peuvent être lancés. Bien qu'il n'y aie aucune formule infaillible sur la création d'une équipe de modding, cette page devrait vous donner quelques idées sur ce qui fonctionne et ce qui ne fonctionne pas.

Qu'est-ce qu'une équipe de modding ?

Simplement, une équipe de modding est un ou plusieurs développeurs qui créent un mod. En réalité, il s'agit d'un ensemble de compétences qui sont mis tous ensemble pour créer un mod. Le code, la création de niveaux, la modélisation, et bien évidemment des idées et de la vision. Bien qu'une personne seule créé rarement un MOD, c'est possible. Pourquoi cela n'arrive pas souvent ? Tout simplement, créer un mod demande beaucoup de travail et des compétences variées. Habituellement, un équipe de développeurs rassemblent leurs compétences pour le projet final.

Qu'est-ce qui compose une équipe de modding ?

Une équipe de modding est faite de petits groupes de personnes, chacun avec son domaine de spécialité, pour couvrir une des quatres rôles du modding : le code, le son, la modélisation, et la création de cartes. Les meilleures équipes sont les plus petites ; trop de membres dans une équipe de modding peut mener à une mauvaise communication, et des parties du jeu incompatibles. Le meilleur type d'équipes est un petit groupe de trois à cinq personnes productif, qui restent tout le long du projet.

Communication et flux de travail

War Stories
Avant que le mod Day of Defeat soit officiellement avec Valve,l'équipe de 8 personne travaillait uniquement avec des messageries instantanées et IRC pour la communication. En fait, l'équipe a développé ainsi pendant tout une année avant de se rencontrer en face. —Tim Holt

La bonne communication est la clé du succès dans n'importe quelle nouvelle entreprise. C'est particulièrement vrai pour les projets comme le modding, lorsqu'une erreur de communication pourrait faire tomber le projet en chute libre. La meilleure méthode est simplement d' être ouvert. Tout le monde doit savoir ce que chacun fait en permanence. Toutes les activités doivent êtres remontées à une personne, qui est responsable de le dire au reste de l'équipe.

Le chef de distribution est un bon choix pour cette place, parce qu'ils sont responsables d'une vue globale du travail pour terminer le mod.Essayez de tenir régulièrement des rendez-vous et d'avoir le plus de membres de l'équipe possible en même temps. Ces rendez-vous ne sont pas seulement un moyen efficace de tenir les personnes à jour, mais permettront également que les membres de l'équipe se connaissent mieux, ce qui est important pour n'importe quel groupe.

Ces rencontres sont meiux avec n'importe quel logiciel VoIP comme Skype, ou messagerie instantannée comme IRC. Une chose qui est toujours pratique est de prendre des notes sur ce qui se passe pendant la réunion. Aller au rendez-vous avec les grandes lignes de ce dont vous avez besoin de discuter, et d'aborder tout de suite le sujet le plus important. Une fois que vous avez ces grandes lignes, restez y fixe le plus possible. Cela va sûrement vous aider à utiliser le temps limité que vous avez pour le rendez-vous effiicacement, il est très facile de s'écarter de sons sujet. Lorsque le rendez-vous est terminé, publiez les notes de manière à ce que toute l'équipe y aie accès. C'est très utile comme une archive au cas où quelqu'un oublie ce qu'il est supposé faire, ou si quelqu'un rate la réunion il peut voir ce qui en est ressorti.Un outil pratique est Writeboard. Il s'agit d'un outil gratuit qui vous permettra de prendre vos notes en ligne avec un accès facile. L'outil peut aussi exporter les notes dans différents formats, et a un flux RSS auquel les membres peuvent s'abonner.

Une autre option est d'utiliser des formulaires de messages, ou un forum. NEVER resort to using email when dealing with the whole group at once. Emails are too easily lost and ignored amongst a group of people. Try to only use it when communicating with specific members.

However you do it, just make sure everyone is on the same page. Make sure everyone knows exactly what is happening, with no ambiguity. It's not the easiest thing to do, but the effort is worth it in the end.


Success, collaboration and teamwork

Good mods don’t usually happen by accident or from the work of mediocre and uninspired people. Before we get into what goes wrong with mods and mod teams, let’s talk about what goes right. What’s worked and what’s been successful.

Teamwork > talent

"Talent wins games, but teamwork and intelligence wins championships."
Michael Jordan

It’s hard to make a good mod without talent. But it’s about impossible without teamwork.

You're far better off working with people who can work as part of a team than people who have skills, but horrible teamwork skills.

Passion, commitment, creativity and drive

War Stories
When the group creating Day of Defeat was still an amateur mod team in its early stages, who was on it was a bit amorphous and ill-defined. But it soon began to gel into a true team as the development got more intense. If it was midnight and the call went out to test something new, it was the same dedicated handful of people who were there every time. —Tim Holt
Your team must be passionately committed to the cause of creating your mod. They must be passionate about what they do and the mod they are creating. Passion doesn't mean fanaticism, but it does mean being there when the mod and the team needs the help. It also can mean a strong sense of curiosity and a desire to explore new things.

You might ask why commitment and passion are hallmarks of a successful team. Mainly because modding is a job that has long hours, probably no monetary reward, and few perks – and you’re not getting paid a thing. In fact you probably have to use your own money to buy software tools, upgrade your computer, and so on. So something has to drive you to keep going.

Problems, team personality, ego and other challenges

The hard and sad fact about mods and mod teams is that most mods fail. They never get beyond the idea stage, or the pre-alpha. There are a number of common themes to what has caused the demise of a lot of mods over the years.

Ego

"A lot of my work has to do with not allowing my characters to have an ego in a way that the stomach doesn't have an ego when it's wanting to throw up. It just does it."
Matthew Barney

Besides apathy and loss of interest, ego and team quarrels are some other things that can destroy mod teams. Some great ideas have vanished because the team members didn't work well together.

The good and bad of personality

Team members will have personalities for better or worse - sometimes for worse. Hidden agendas, bullies, those that either can't give respect, drama queens and non-contributors are a few examples.

You do the work, I'm the leader/idea person

"I GOT A GREAT IDEA FOR A MOD BUT I JUST NEED LEIK MAPPERS N SKINNERS N CODERS N STUFF! OMG EMAIL ME!"
l33tmodderhax0rdude@hotmail.com

This kind of plea for help on a mod is laughable, but actually common. Someone with no actual technical talent in mod development has a "great" idea, and just needs to get basically the entire team to come help. Oh, and they will be the leader and the "idea person".

Who leads?

"It is very comforting to believe that leaders who do terrible things are, in fact, mad. That way, all we have to do is make sure we don't put psychotics in high places and we've got the problem solved."
Tom Wolfe

Who should lead a mod team, if anyone? How does a MOD team set goals, communicate publicly as one, and generally keep going?

What is leading anyway?

Leading is anything that keeps the mod moving forward in a semi-coordinated way towards a shared goal.

Everybody leads model

War Stories
IMO, ELM works least. Sapphire Scar for Doom 3 had this model: the team started off well, and a lot of work was done, but every time some one did not like something a new poll would pop up on the forums and create a massive 5 page talk. Only use this model if you live near each other, as ELM can kill a team, and a project. —Adam McKern
In this model, everyone on the team has an equal voice. It can be successful if everyone both contributes but also most importantly respects the opinions of their team mates. As soon as you begin to resent or dislike the work or opinion of a team mate, you will inevitably begin to see yourself as being superior to them.

Nobody leads or creative anarchy model

Here, the people with the most drive and creativity (those who crank out the most work) lead by default, simply because they are doing stuff. They are making the mod go forward by virtue of their own drive. If they slack off or take a break, others take up the challenge.

A leader leads

One person (or a subset of the team) calls the shots and leads the mod development.

Starting a project and building a team

A lot of mods will begin as ambitious projects but will most likely flop this way. For example, you might want a game where you fight with swords and magic, an overambitious mod leader will talk about it for a while and try and get someone to make the models and sounds required and never get the code finished. When this happens you have to start thinking smaller.

It helps to start small. If you want a big total conversion mod start by making a mod that has some of the features you want in it. For example, if you want to make a HL1 MOD that rips off Perfect Dark, start by changing HLDM to have some of the features of that game. Add a 'radar', change the weapon behavior a little and people will see that things are being done. When a potential team member sees your site or moddb profile and sees progress despite the lack of art they will be more impressed.

The above example of the PD ripoff was a real mod that gained many members a month after a small (barely) playable demo of some features was released and went on to be somewhat successful. But you don't have to release every little thing to the public, post some screenshots or other media that shows off your progress.

Niche mods

Wally!
The amount of crap that is posted in the ModDB forums is nothing short of depressing. Make a mod because you have a neat idea, not because you want to recreate your favorite anime series! C&Ds aside, your mod will likely have weak gameplay and be a complete chore to build once you're done importing the sounds and textures. —Tom Edwards
A common problem with modifications is having the potential for only a small fanbase. These are the old game remake mods, the Dragon Ball Z mods, the mods based on some obscure movie or show. Recently a mod tribute to Trigun went under due to lack of support and although there were plenty of fans of Trigun who wanted to play, few were actually able to help.

By narrowing your fan base, you narrow your potential team members. People will only work on a mod they will play. Be prepared to fight tooth and nail for the few modders you find in your community as they will be hard to come by.

When not to start a project

"He who knows when he can fight and when he cannot will be victorious."
Sun Tzu

Don't start a mod when:

You have an incomplete plan
Make sure you have at least a high-level overview of how everything will fit together before you start publicising and getting a team together.
You have no idea how your design will play
Always build a prototype of some sort. Garry's Mod offers Lua scripting, which makes producing one far easier than it has been in the past. You may even be able to crowbar some of your features into an existing game without any code. Anything to get the mechanics working. Plus, a prototype will make you appear far more convincing when organising a team. If building a playable prototype is too difficult, then building a mod will be far worse!
You aren't 100% confident you can do it
Don't be afraid to keep ideas to yourself for months, even years, if they don't seem feasible. Write them down, come back to them every now and again when you think of something, and keep an eye out for others solving the problems you got hung up on. Never ditch an idea outright!
You are waiting for more powerful hardware/software
You might end up waiting too long and find you and your team losing interest.
You are about to become very busy
Be patient, and wait!
You have only just finished assembling a team
Get to know them, do concept work, test the waters and cut the dead wood BEFORE committing.
Everyone else is doing the same thing
Observing other people's efforts will strengthen your own. This isn't a race!

See also

External links