Es/Making a Mod
Template:Otherlang2 Template:Finishtranslation:es Este artículo está diseñado para orientarte a la hora de dar los primeros pasos en la modificación del Motor Source, proceso también conocido como crear un mod. En primer lugar, se encuentran listados una serie de consejos sobre cómo comenzar un mod y organizar el equipo. Seguidamente, se ofrece una serie de pautas útiles para determinar el diseño de juego de tu mod, y por último, podrás consultar una completa guía de cómo atar los cabos sueltos y concluir tu mod, normalmente la parte más difícil y compleja.
Primeros Pasos
Comenzaremos hablando de cómo organizar un equipo. La regla básica y primordial es mantenerlo lo más reducido posible, ya que controlar un grupo de trabajo es una tarea que requiere mucho tiempo y dedicación, incluso cuando todos los miembros residen en el mismo lugar. En el caso de que estés colaborando con un equipo a través de Internet, puedes incluso invertir exclusivamente todo tu tiempo en coordinarlo y dirigirlo, dejando de lado la propia creación de tu mod. Es por ello que debes tener en cuenta que incluir más gente no es sinónimo ni de mayor calidad, ni de más trabajo en menos tiempo. Para que te hagas una idea, el equipo central de Team Fortress está formado por tres personas, mientras que el del Counter-Strike está formado por tan sólo una.
Lo más normal es que tu primer impulso sea incluir en tu proyecto a cualquier persona que pueda programar, crear mapas, modelar, etc. Pero para tu primer mod, probablemente no necesites más de una persona por cada área. Puede incluso que ni siquiera necesites ningún modelo, sonido o mapa nuevo. Por eso, cuando te lances a la búsqueda de miembros para tu equipo, intenta incluir únicamente a la gente indispensable. Sé selectivo y no incluyas a nadie sin antes haber visto ejemplos terminados de su trabajo: Un modelador con 20 modelos inacabados no es útil para tu proyecto.
Diseño del Mod
Como autor de tu mod, debes plantearte una serie de preguntas básicas: ¿Por qué alguien debería jugar a mi mod? Es más, piensa ahora en los otros mods que hay ahí fuera y lo que ofrecen. ¿Ofrecerá tu mod algo nuevo a los jugadores? ¿Aquello que ofreces será lo suficientemente atractivo como para atraer a los jugadores de otros mods? La respuesta a estas preguntas no es fácil, pero si eres capaz de encontrar una buena solución, significa que vas por buen camino. Sin embargo, no te preocupes: tómate tu tiempo y reflexiona, el simple hecho de pensar en estas preguntas ya contribuirá a mejorar de manera significativa tu mod.
Compite con la jugabilidad
Una de las ventajas que posees frente a los desarrolladores comerciales es que no tienes que preocuparte acerca de si la jugabilidad de tu mod será viable de manera económica, permitiéndote experimentar con nuevas ideas que pueden llegar a convertirse en una gran innovación. Esta es la ventaja que debes explotar al máximo. No inviertas tu tiempo intentando competir en aquellas áreas en las que los productos comerciales tienen un gran poder: La mayoría de ellos tienen equipos de artistas con varios años de experiencia en el sector. Simplemente, derrótalos con una brillante jugabilidad. Los jugadores preferirán un mod que tenga muy poco contenido pero que tenga un estilo de juego realmente divertido e innovador. Por ejemplo, Team Fortress 1 no tuvo ninguna innovación artística durante un año después de su primera aparición, sin embargo, fue todo un éxito.
Publica rápido y de manera regular
Otra de las ventajas que posees sobre los desarrolladores comerciales es que puedes publicar más y con mayor frecuencia de lo que ellos pueden hacer. Mientras que las empresas trabajan durante 2-3 años, lanzan su juego, y rezan para que a la gente le guste, tú no tienes que realizar ese acto de fe. Puedes diseñar únicamente una parte de tu mod y lanzar una versión jugable, recibiendo feedback de manera inmediata. Después, y basándote en esas opiniones, puedes comenzar a completar tu mod pieza por pieza como si de un puzzle se tratase. De esta manera estás en contacto continuo con tus jugadores, sabiendo de primera mano qué es lo que funciona en tu mod y lo que no. El truco está en dividir tu mod en partes: La versión inicial necesita ser divertida y jugable, pero no necesita tener todos los elementos que tienes pensados.
Pero ten cuidado, publica rápido no significa que desarrolles elementos de mala calidad, significa que desarrolles tu mod en pequeñas partes que puedan ser ampliadas poco a poco. La primera versión de Counter-Strike no tenía ni la mitad de cosas que tiene ahora, el equipo del CS optó por ir creciendo poco a poco, y en respuesta, su comunidad de jugadores ha ido creciendo y creciendo.
Ser diferente no siempre es ser mejor
Cuando desarrolles el diseño de tu juego, no caigas en la trampa de pensar que hacer algo diferente es siempre lo mejor. No existen razones para reescribir el código de un arma y crear un nuevo modelo de ella si no afecta a tu juego de manera significativa. Ten siempre en mente la primera pregunta: ¿Por qué alguien jugaría mi mod? Si la respuesta es Mi mod tiene un nuevo sistema de combate y de movimiento no implica que esta sea la mejor respuesta. Así que si tu sistema de combate es diferente que en el Half-Life... bien, ¿Pero es lo mejor? ¿Hace a tu mod más divertido? ¿Hace ese nuevo sistema de movimiento más divertido el juego? Los jugadores están acostumbrados a los sistemas que ya existen, y para hacerles aprender uno nuevo implica que éste valga la pena. Así que antes de pensar en cambiar algo, estate seguro de que sabes que el cambio es a mejor y de que ello hará a tu mod más divertido. No te asustes por dejar algo tal y como era en Half-Life.
Fija objetivos realistas
Por un momento, piensa en todo el tiempo que invierte una empresa profesional en sacar un juego con tan sólo diez armas. Si planeas publicar un mod con más de cuarenta armas, lo único que estás haciendo es fijar unos objetivos totalmente irreales. Dichos objetivos serán muy difíciles de cumplir, y lo único que harán es aumentar tu frustración y agobio al no ver que no los puedes cumplir. No te compliques y simplifica tu trabajo: elimina todo aquel contenido y características que tu mod no necesite. Durante el desarrollo de Half-Life al menos el 30% de las características diseñadas originalmente fueron eliminadas debido a que se excedían de los objetivos fijados por el equipo de trabajo. Ten en cuenta que la calidad prima sobre la cantidad, y que los jugadores preferirán tener tres mapas de gran calidad que diez mapas mediocres. Una gran calidad en tu trabajo será sinónimo de una reputación de calidad, pero cuidado, nunca le dejes ver al mundo tus peores creaciones.
Entiende el motor Source
Si de verdad quieres modificar y trabajar con el motor Source, deberás primero leer detalladamente la documentacion incluida dentro del SDK. Lo que aprenderás no es si se puede hacer algo con el motor Source, sino qué tengo que hacer para que ese algo funcione en el motor Source. Por ejemplo, quieres crear una pistola que dispare 50 cohetes, pero si no entiendes de la manera en la que el motor funciona, puedes hacerlo de un modo que incremente significativamente el tráfico de Internet cuando se use tu mod. Si tu creador de mapas no entiende el engine, hará grandes mapas sin pensar en cuánta información será enviada a los jugadores en ellos, y todo el mundo va a criticar tu código por consumir mucha banda ancha. De esta manera, lo único que conseguirás será un mal acabado y un pésimo funcionamiento que repercutirá en la calidad final del mod. Si eres un programador, es recomendable que te unas a la mailist de programadores, donde podrás hablar con otros programadores de mods en incluso con algunos empleados de Valve. Por otro lado, no dejes de visitar el archivo de la mailist donde se da solución a los problemas más comunes a la hora de crear un mod.
Finalizando tu mod
Es muy común ver muchos mods que empiezan fuerte, con una gran cantidad de artwork, concepts y modelos, pero que sin embargo nunca llegan a publicarse. Esta sección te proporcionará una serie de pautas para ayudarte a obtener un modo de lanzamiento que te conducirá a la producción de la versión final de tu mod.
Estableceremos cinco semanas como tiempo estimado para convertir una versión de desarrollo en una versión pública, aunque si se trata de un mod de gran envergadura o tu equipo posee una proyección internacional, es probable que el tiempo sea mayor que las cinco semanas establecidas (aunque los pasos que veamos serán prácticamente los mismos). Si es posible, intenta que todo el equipo dedique unas horas al día al proceso de finalización del mod. Si alguno de los miembros no puede llevar a cabo esta tarea, será mejor que lo dejes fuera de este proceso. No se trata de nada personal, sino que esta etapa requiere de una gran implicación y esfuerzo por parte de todos los integrantes del equipo de trabajo.
Por muy fuertes que puedan sonar los comentarios expuestos en esta sección, no es más que la realidad que te vas a encontrar ahí afuera. Aquí se encuentran recopiladas las lecciones aprendidas a base de numerosos errores y duros golpes que hicieron retrasar incluso nuestras propias fechas de lanzamiento. Cuando te preguntes si era necesario ese consejo en algún tema en concreto, es probable que nosotros hayamos retrasado varias semanas nuestro trabajo por no seguir ese mismo consejo.
Esto es algo en lo que también están muy interesados los posibles trabajadores. Una cosa es ver que un modder ha creado una gran cantidad de material molón y otra totalmente distinta es ver un modder que ha creado una gran cantidad de material molón y que además lo ha publicado de manera que la gente lo pueda probar y jugar con el. Nunca olvides que el mapa/modelo/código/sonido/etc. más molón del mundo no sirve para nada si no consigue llegar al público.
¡No tengas miedo, una vez que hayas pasado un par de veces por esta fase y vayas por el cuarto o quinto lanzamiento de tu mod, te habrás convertido ya en todo un experto!
Five weeks out
Centralize ownership
You should designate a single member of your mod team as the Shipping Leader (SL). This person will drive progress on the mod for the next five weeks. All changes made to the mod from now on should occur only at the request of the SL, and all requests for changes should be funneled through this person. No team member should make any changes, no matter how minor, to the mod unless the SL has requested that they make a particular change. This doesn't mean the rest of the team are losing control of the mod; the SL is still a part of the team, and will be listening to all feedback. The point of the SL is to ensure that all changes to the mod are going through a single person. This avoids problems such as a mapmaker breaking the game by making a last minute change because he didn't realize something else had changed in the game code. The SL will know the state of every component in the game (code, maps, models, textures, etc) at all times throughout the next 5 weeks to ensure this never happens.
Choosing the SL isn't easy. Here are a few tips:
- Don't immediately assume the person who's currently running the mod is the best choice for SL, especially if the mod has been worked on for months and hasn't got any closer to being released.
- Game Coders are probably the best choice. As the shipping process comes to an end, most fixes will be made in the game code.
- The SL should be highly motivated, disciplined, organized, and as ego-less as possible. The SL will need to be able to commit five weeks of his or her life to this process.
- The SL should be able to make global decisions for the mod. The SL should understand that this often requires cutting features and content in order to ship
Establish a build process
You need to create a process by which you build your mod. Building is the process of taking all your work and producing an installable, working version of the mod (generally in the form of an install file). This should be done exclusively by the SL for the next five weeks, and the SL should have a strict process that is always followed. Creating a strict process for this will ensure you don't waste hours tracking down bugs that are simply a result of someone building in a different way than the previous person.
The SL should maintain the final/release candidate version of the mod from now on. All changes should be sent to him, and he should incorporate them into his copy of the mod one by one and with a full understanding of the impact of the changes on all parts of the mod. Don't forget to backup your code and content regularly!
The SL should build the mod every day for playtests. More on that later.
Feature locking
Shipping is the process of locking down portions of your mod. "Locked" means that the portion is not to be touched from then on. Bugs found in locked portions of your mod should be thought about carefully. Unless the bug is really important (showstopper), just note it down and fix it in the next update of your mod. Regardless of the temptation to make that one "easy fix", unlocking portions of your mod should be avoided as much as possible.
At this point in the shipping process, five weeks out, you should also be feature locked. This means you shouldn't be adding any new features to your mod whatsoever. If part of your team is not involved in shipping but wants to continue working on developing the mod, they should be working in a separate content and code database. Most source code control packages allow for branching of code in this fashion. (Yes, we strongly recommend that you use some form of source control ). Every change made to the mod from now on should be a bug fix. The SL should ensure this. Even if a coder thinks of another cool feature that they say will only take them 10 minutes to code, do not let them add it in. Even if the coder sends the code, finished and bug-free, to the SL, do not add it to the mod. Save it for the next version.
A healthy attitude for the SL to have is that every change to the mod from now on will add two days to the release date.
Playtesting
From now on, you should be running playtests every day, or every second day if that's too much. Playtests should be based on installable versions of the game, built by the SL. Don't let team members play from their personal versions of the game. Everyone should be running a version of the mod installed from a build sent out by the SL (that's what your viewing public will be installing and using, that's what you should be testing). You'll waste many hours on finding bugs caused by incompatible versions if you don't do this.
To make this easier, the mod must be kept in a playable state at all times. Get very, very worried for every day the mod isn't playable. If a coder or mapmaker makes a change that breaks the mod, think about it carefully before incorporating it into the SL's build. How long will the game remain unplayable? How many playtests will you miss? How many team members won't be able to work because the mod isn't running? Not breaking the mod should be religion for the team.
When you do playtest, make sure as many of your team members are playing as possible. Everyone working on the game should be playing it regularly. Make sure you have some external players as well. Turn on server console logging (set "log" to "on" in the server.cfg file). This will dump all the output of the server into a file in the gamedir/logs directory ( the name of the file will match the date). Whenever any player in the game spots a bug, have them use their "say" key to say "BUG: description of bug". Then, when the game is over, you can open up the log file and get all the bugs out of it by searching for the word "BUG."
Bugs and changes
The SL should maintain a complete list of all bugs and changes, and their current status. Preferably this should be done using some kind of true database. E-mail is totally insufficient for tracking bugs; it's just too easy for items to drop of the first page of a user's mailbox, etc. After each playtest, the bugs and necessary changes from the log file should be added to the list by the SL, and assigned to team members. When a team member has fixed a bug or change, they should submit the new content to the SL, who should verify that it is fixed and then update the status on the bug list.
The bug list is a fantastic tool to evaluate how well you are progressing. It can be used to find out who is overloaded with work, who is underloaded, who is not fixing his bugs, which area of your mod is farthest from completion, and so on. Don't remove anything from the bug list, even when it has been fixed (though you should mark it as fixed in some way, of course). It's very useful to see what bugs have been fixed throughout the history of the project. Something might regress, re-creating a bug, and knowing who fixed it last time makes it easy to ask them what caused it. At the end of the project, you should be able to see every bug fixed and every change made in your mod for the entire shipping process. The SL shouldn't allow any bug fix or change into the SL's master copy of the game unless the bug/change has been detailed in the bug list.
There is software that will help you create and maintain a bug list. Alternatively, a spreadsheet will work just fine. Again, e-mail is a bad choice.
Cut or defer broken features
The hardest, nastiest, and unfortunately most necessary part of shipping is the act of being realistic and cutting features. We have a saying at Valve that everyone will have their favorite feature cut from the game. While it's not true, it does help everyone prepare themselves for the fact that they will have features they like -- or that they spent some to a lot of time on-- cut. Your game simply cannot have every cool feature and still ship in a reasonable time frame. The SL should make decisions about what to finish and what to cut, based on how far along in the release process you are.
The closer you get to releasing, the more you should think about each bug as you find it. Is the bug in a feature that absolutely must be in this version? How many days will it take to fix this feature? Can this feature be cut, or deferred to a later version?
Work smart, not hard
As we've said over and over again, the shipping process is hard, and it's even harder if you don't think carefully about what to work on. Working a lot is no substitute for carefully choosing what to fix, what to defer, and what to cut out altogether. The SL should be extremely careful about which bugs/changes should be worked on, and by whom. Don't spend a week fixing a minor problem in a feature just because the feature is cool. Fix crash bugs (showstoppers). Fix bugs that utterly prevent you from shipping the game. Fix bugs that are preventing other team members from fixing their bugs. The SL should develop categories for bugs to aid in making the right decisions. A good level of granularity is Must Fix, Severe, Medium, Minor, Zero, Deferred.
As the project gets closer to shipping, the SL should be carefully evaluating every bug that shows up. Remember, every bug that's fixed creates more playtesting, and usually more bugs. If you are two weeks from your release date, and you've got a bug that will take someone three days and 500 lines of code to fix, you're not going to make that release date unless you cut or defer that portion of the game.
Three weeks out
Content Locked
By now you should aim to be content complete. This means that all content in the game is in a locked state, except for the game code itself. All the maps, models, textures, sounds, HUD art, launcher art, and so on should be finished and in the SL's master copy.
Shutting down
This was mentioned at the five week mark, but it's even more important now. The SL is the only person who should be touching the master copy of the game, and he should simply be rolling in the bug fixes from the coders, who should be fixing only the bugs the SL hands them.
Playtesting
The mod should be being playtested every day, for at least two hours. Between now and when you ship, you want as many people as possible hammering away at your mod. It's too late now to make any major game design changes – don't even be tempted.
One week out
No last minute changes
The SL should be evaluating every change that has to be made, and deciding whether they should be deferred to the next version. Again, a healthy way to think about it is that every single change, even if it's a single line of code, will add two days to the release date.
Two day safe period
Once every bug that is going to be fixed has been fixed, and everything else has been deferred, you're not done. Now you wait at least 48 hours, during which time you should playtest like crazy. Try to get everyone hammering away at the game for as much time as possible. If you find any more bugs that have to be fixed, fix them, and start the 48 hours again.
If your mod passes 48 hours of heavy playtesting without finding any new issues, you're ready to release!
Post-release
So you've released, the players love it, and web pages everywhere are talking about how much fun your mod is. Whether you're done now is up to you. From our experiences in the on-line multiplayer field, a mod only stays popular as long as it's supported. No matter how great your mod is, it's not going to garner really significant player numbers with its first version. Player numbers are grown over time through repeated releases of new content, bug fixes, and of course, community support. Both Counter-Strike and Team Fortress started out small and grew over time. Each time they released a new version, more players tried them out and started playing them.
Knowing what to fix, what to change, and how to listen to your community is a continual learning process.
Good luck!