Es/Making a Mod

Template:Otherlang2 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!

Primera semana

Designar un Shipping Leader

Lo primero que debes hacer es designar a un único miembro de tu equipo como el Shipping Leader (SL), el cual se encargará de llevar el progreso del mod durante estas cinco semanas. Todos los cambios que se realicen al mod a partir de ahora ocurrirán únicamente cuando el SL lo pida y siempre bajo su estricta supervisión. Ningún miembro del equipo puede realizar ningún tipo de modificación, por muy pequeña que sea, sin que el SL se lo haya pedido expresamente. Por supuesto, esto no significa que el resto del equipo pierda el control sobre el mod: el SL seguirá siendo parte del equipo y como tal, escuchará y tomará nota de todo el feedback que se le proporcione. La clave reside en que los cambios que se realicen al mod pasen únicamente por una sola persona, evitando de esta manera problemas como que un mapper "rompa" el juego debido a que ha hecho un cambio de última hora sin saber que el código del mod había cambiado. El SL tiene la responsabilidad de conocer exactamente el estado de cada uno de los componentes del juego (código, mapas, modelos, texturas, etc.) así como los cambios que se van realizando en los mismos durante las próximas cinco semanas para asegurarse de que no se cometa ningún error.

Elegir un SL no es fácil, sin embargo aquí tienes algunos consejos:

• No des por hecho que la persona encargada de llevar a cabo el mod sea la mejor opción para desempeñar el cargo de SL, especialmente si el mod está en desarrollo desde hace meses y todavía no está listo para ser publicado.
• Los programadores son probablemente los mejores candidatos a SL: Hasta que el mod sea publicado en su versión final, la mayoría de los fallos que haya que corregir serán en el propio código del jugo.
• Un buen SL es alguien con un alto nivel de disciplina, ordenado, con gran motivación y muy modesto. Además deberá contar con que tendrá que invertir plenamente cinco semanas de su vida en este proceso.
• El SL deberá poder tomar decisiones de ámbito global y que afecten a todo el mod. Esto significa que en ocasiones tendrá que eliminar contenido y diversas características para poder ajustarse al plazo fijado.

Establecer un proceso de compilación

La compilación es ese proceso que convertirá todo tu trabajo en una versión instalable y funcional de tu mod, por lo que es muy importante establecer una serie de pautas y de normas. Dicho proceso deberá llevarse a cabo única y exclusivamente por el SL para garantizar un control estricto del proceso durante estas cinco semanas. De esta manera, os evitaréis el corregir bugs creados por que alguna persona del equipo está compilando con una versión distinta a la del resto del equipo.

A partir de ahora, el SL será el encargado de mantener la versión RC (release candidate), añadiendo todos los cambios que le hayan sido enviados y conociendo en todo momento las consecuencias que esos cambis implican en el mod. Además, deberá compilarlo todos los días para poder realizar el playtest. ¡No olvides realizar copias de seguridad con frecuencia!

Ve cerrando partes

Durante estas semanas, tu mod llegará a un punto en las que diversas partes del mismo serán cerradas, lo que significa que ya no se podrá volver a tocar esa parte. Si por un casual se encontrase un bug en alguna parte bloqueada del mod, debes sopesar seriamente si ese bug es muy grave, o si por el contrario puede esperar a ser solucionado en la próxima actualización del mod. Evita a toda costa el abrir partes de tu mod ya cerradas para realizar pequeños arreglos, ya que estos aumentan las probabilidades de cometer más errores.

Es conveniente también dejar cerradas las principales características de tu mod, lo que quiere decir que llegados a este punto, no se va a añadir ninguna característica adicional sea cual sea. Si una parte del equipo no se encuentra trabajando en el proceso de publicación, y desea seguir desarrollando el mod, deberán hacerlo con un contenido y un código de base de datos totalmente distinto. La mayoría de los sistemas permiten un control del código fuente para recopilar las distintas versiones de los códigos (Si, recomendamos encarecidamente que establezcas algún método de control del código fuente) A partir de ahora, los únicos cambios que se deben realizar al código fuente serán para arreglar exclusivamente los posibles bugs bajo la supervisión del SL. Aunque un programador te diga que tiene una nueva función muy molona y que tan sólo le llevará diez minutos escribir el código, no dejes que la añada. Es más, aunque te envíe el código terminado y sin bugs, no lo incluyas en el mod. Guárdalo para la próxima versión. Una buena actitud para un SL es que cualquier cambio que se realice al mod a partir de ahora, conllevará dos días de retraso en la fecha de lanzamiento.

Playtesting

De ahora en adelante deberás realizar sesiones de playtest cada día, o cada dos días como mucho. Dichos playtest deben estar basados en versiones instalables del juego y compiladas por el SL. No dejes que los miembros del equipo jueguen con las versiones que ellos mismos han compilado puesto que todo el mundo debería ejecutar la misma versión del mod proporcionada por el SL. En caso contrario, malgastarás el tiempo intentando solucionar bugs provocados por la incompatibilidad entre versiones.

Para hacerlo mucho más fácil, el mod debe permanecer siempre en un estado jugable. Preocúpate mucho no, muchísimo por cada día en el que el mod no sea jugable. Pero ten cuidado: Si un programador o un mapper desea realizar un cambio, el SL debe estar completamente seguro que éste no suponga ningún riesgo para el mod, de lo contrario, podría volverse completamente inestable. ¿Cuánto tiempo continuará siendo el mod injugable? ¿Cuántos playtest se perderán por este fallo? ¿Cuántos miembros del equipo no podrán trabajar dado que el mod no funciona? Tener una versión totalmente estable debe ser la máxima prioridad del equipo.

Cuando realices las playtest, intenta que jueguen la mayor cantidad posible de miembros del equipo así como algunos jugadores externos. Activa además el log de la consola (En el archivo server.cfg configura el parámetro "log" en "on") Esto volcará toda la actividad del servidor en un archivo de texto dentro de la ruta gamedir/logs (el nombre del archivo corresponderá con la fecha en la que se jugó la partida)de esta manera, cada vez que cualquier jugador detecte un error, podrá usar la tecla "Hablar a todos" (Por defecto la letra Y) y escribir "BUG: descripción del bug". Cuando acabe la partida, podrás abrir el log de la partida y obtener todos los bugs encontrados realizando una búsqueda por la palabra "BUG".

Bugs y cambios

El SL debe mantener un listado completo de todos los bugs y cambios que se realicen en el mod, así como su estado actual. Preferiblemente, deberá realizarse mediante algún tipo de base de datos. El correo electrónico es totalmente insuficiente para llevar un listado de los bugs: es muy fácil que un correo se borre, se pierda en la bandeja de entrada, no sea visto, etc. Después de cada playtest, los fallos y los cambios que se necesiten hacer a mod, deben ser añadidos a la lista por el SL y asignados a los distintos miembros del equipo. Cuando un miembro del equipo haya arreglado un fallo o haya introducido un cambio, deberá enviar el nuevo contenido al SL, el cual verificará que el fallo ha sido corregido y actualizara su estado en la lista de bugs.

El listado de bugs es una herramienta fantástica para evaluar vuestro progreso. Puede ser usada para encontrar quién tiene un exceso de trabajo, quién tiene poco que hacer, quién no está arreglando sus bugs, qué área del mod está más lejos de ser completada, etc. No elimines nada de la lista de bugs (puedes indicar en un lateral que ese fallo ha sido arreglado) ya que es muy útil saber qué bugs han sido arreglados a través de la historia del proyecto. Puede que en alguna ocasión se repita el mismo bug, y sabiendo cómo se arregló una vez, será más fácil arreglarlo una segunda. Al final del proyecto, deberías poder ver cuáles han sido los fallos y los cambios realizados durante esta etapa. El SL no debe permitir ningún tipo de cambio en la lista maestra de bugs a menos que dicho bug no haya sido incluido en la lista.

Existen programas que te ayudarán a crear y mantener la lista de bugs, aunque como alternativa también se puede utilizar una hoja de cálculo. Recuerda que el correo electrónico no es una buena opción.

Eliminar o aplazar las características que no funcionen

La parte más dura, desagradable y desafortunadamente la más necesaria de este proceso es la de ser realista y eliminar aquellas funciones que sobren del mod. Tenemos un dicho en VALVe que dice que la funcionalidad favorita de cada miembro del equipo será eliminada del juego. A pesar de que esto no es verdad, nos ayuda a afrontar el hecho de que, a pesar de que el juego tendrá características nos gusten, no todas tienen cabida en el juego final, y que por lo tanto, algunas características serán eliminadas si se quieren cumplir unos plazos de tiempo razonables. El SL deberá tomar las decisiones acerca de qué se debe y qué no se debe terminar, basándose en el estado en el que está el proyecto y cuánto tiempo queda para publicarlo.

Cuanto más te acerques a la fecha de lanzamiento, mas deberíais pensar en cada error que encontramos. ¿Es una característica absolutamente necesaria en esta versión? ¿Cuántos días se tardaría en arreglarla? ¿Esta versión puede ser eliminada en esta versión y ser implementada en otra posterior?

Trabaja de manera inteligente, no es difícil

Como ya hemos dicho anteriormente, el proceso de publicación es duro, y lo es todavía más si no piensas de manera cuidadosa en qué hay que invertir el tiempo. Trabajar mucho no es una excusa para elegir minuciosamente qué se debe corregir y qué se debe eliminar por completo. El SL debe ser extremadamente cuidadoso a la hora de elegir qué bugs/cambios deben ser corregidos y por quién. No gastes una semana arreglando un problema menor en una característica únicamente porque esa característica sea guay. Arregla los bugs que crasheen el juego, que retrasen el lanzamiento del juego o que incluso impidan que el resto de compañeros arreglen los suyos. El SL debe clasificar los bugs en una serie de categorías para para ayudar a tomar las decisiones correctas. Un buen sistema de clasificación sería: Arreglado, Grave, Medio, Menor, Cero y Aplazado.

Conforme el proyecto se acerque a la fecha de lanzamiento, el SL tendrá que evaluar cuidadosamente cada bug que aparece. Recuerda, cada bug que es arreglado crea más sesiones de playtesting, y más sesiones de playtesting significan más bugs. Si estás a dos semanas de la fecha de lanzamiento, y tienes un error que costará tres días de trabajo y quinientas líneas de código a arreglar, no podrás cumplir el plazo estimado, a menos que elimines la funcionalidad o aplaces esa parte del juego.

Cuarta Semana

Contenido bloqueado

A estas alturas, el contenido del mod debe estar completametne acabado y cerrado a excepción del código fuente. Esto significa que los mapas, modelos, texturas, sonidos, arte, HUD, etc. han sido correctamente finalizados y almacenados en la copia maestra del SL.

Para terminar

Aunque ya lo hemos comentado en el apartado de "Primera Semana", en este momento adquiere una especial importancia. El SL es la única persona que deberá tocar la copia maestra del juego y únicamente se limitará a añadir los bug fixes de los programadores, los cuales arreglarán exclusivamente aquellos fallos que el SL les diga.

Playtesting

El mod debe ser probado cada día durante al menos dos horas. Entre ahora y la publicación del mod, intenta conseguir un buen número de personas que pongan a prueba tu mod. Ya es demasiado tarde para realizar cambios importantes en el diseño del juego, ni tan siquiera pienses en ello.

Quinta semana

No hay cambios de última hora

El SL debe evaluar todos los cambios que tienen que ser hechos y decidir si deben ser tratados en la próxima versión. De nuevo, una buena forma de pensar, es que por cada fallo que se arregle, se retrasará dos días la fecha de lanzamiento.

Las 48 horas de seguridad

Una vez que todos los bugs que tengan que ser arreglados hayan sido convenientemente arreglados, y todo lo demás haya sido aplazado, todavía no has acabado. Ahora debes esperar al menos durante 48 horas, tiempo en el que deberás hacer playtests como un loco. Si encuentras más bugs que deban ser arreglados, arreglálos y comienza de nuevo las 48 horas. Si tu mod ha superado las 48 horas sin encontrar ningún bug que deba ser arreglado ¡Estás preparado para el lanzamiento!

Después del lanzamiento

Así que ya has lanzado tu mod, los jugadores lo adoran y todas las páginas web del mundo están hablando de lo divertido que es tu mod. Lo que hagas a partir de ahora dependerá exclusivamente de tí. De nuestra experiencia en el ámbito de los videojuegos multijugador online, un mod sólo mantiene su popularidad tanto tiempo como sus desarrolladores decidan darle soporte. No importa lo genial que sea tu mod, ya que no reunirá una cantidad significativa de jugadores en su primera versión. El número de jugadores crece con el tiempo y a través de actualizaciones de contenido, corrección de errores, y por supuesto, el apoyo de la comunidad. Tanto el Counter-Strike como el Team Fortress, fueron creciendo conforme se iban lanzando nuevas versiones.

Saber qué se debe corregir, qué se debe cambiar y cómo escuchar a la comunidad, es un proceso de aprendizaje continuo.

¡Buena suerte!

Ver también

• Shipping Leader In Detail
• Mod Packing & Shipping
• Category:Modding