Estoy trabajando solo en un proyecto de juego cuyo desarrollo podría separarse en 3 partes independientes (generación de mapas, el motor "supramundo" y el motor de batalla), pero a medida que avanza el desarrollo, no estoy seguro de cómo debería tratar. La gestión de este proyecto, especialmente en relación con estos 3 puntos:
¿Vale la pena usar un sistema de control de versiones, ya que estoy trabajando solo?
¿Debo usar un método formal para registrar características / errores planificados (solo recuerdo lo que hay que hacer por ahora)
La pregunta más importante: ¿cómo puedo saber qué desarrollar primero? Ahora que se han hecho los conceptos básicos, conozco la lista de características para codificar, pero no sé en qué orden debería hacerlo.
project-management
lezebulon
fuente
fuente
Respuestas:
Yo usaría:
1. Gestión del código
GIT (y la increíble referencia ), un administrador de código fuente distribuido, para administrar mi código y alojarlo en GitHub como un proyecto privado si quiero mantenerlo fuera de los límites.
(Hay MUCHAS opciones aquí, solo google para la administración del código fuente, ni siquiera NECESITA usar GitHub ni ningún otro sitio web, Git funcionará bien en su computadora local, pero usar GitHub hará el trabajo de administrar copias de seguridad mucho más fácil.
Si tiene dos computadoras, puede crear un repositorio en una que llamará su máquina de respaldo, luego clone ese repositorio en la red local y lo use para el desarrollo, cuando haya terminado con una característica, puede llevarlo al copia de seguridad de la máquina y tendrá una copia de seguridad 1: 1!)
2. Gestión de problemas y funciones
Utilizaría la gestión de problemas integrada de Trello o GitHub para realizar un seguimiento de errores y cosas que hacer.
3. Tener un proceso de diseño
Primero diseñaría mi juego;
4. Usar mi prototipo como guía y desarrollar mi juego
Luego dejaría mi prototipo a un lado y elegiría una plataforma para la que deseo desarrollar. Luego busca motores existentes y elige el que mejor se adapte a mi idea de juego. Luego, establecería objetivos claros para mi proyecto, los estructuraría en pequeñas tareas y luego comenzaría a trabajar para terminar las tareas. Cuando haya alcanzado este estado, lo más probable es que descubra que tiene su propia forma de trabajar que más le convenga, ¡así que vaya con eso!
Existen varias metodologías / filosofías diferentes que puede aplicar en su estilo de desarrollo, XP, Cascada, etc. Simplemente siga la que cree que le permite progresar más rápido.
5. ¡Ten muchos probadores de juegos!
Cuando tengas algo jugable, ¡pide a tus amigos inmediatos que lo prueben! Facilíteles la ayuda mediante la configuración de paquetes de instalación rápida si están ejecutando Windows o escriba algún script de shell que pueda automatizar el proceso si están usando Linux / Mac. Tenga mucho cuidado con los comentarios de sus evaluadores, y no olvide informarles sobre el diseño de su juego y qué tipo de juego está tratando de construir.
6. Hacer un sitio web para mi juego
Tan pronto como tenga algo bien, probablemente haría un sitio web para mi juego, para mantener mi creatividad y contenido fluyendo cuando no se puede aplicar al progreso de mi juego, por ejemplo, si me estoy enfocando en mis estudios o necesita un descanso del desarrollo!
Si uso GitHub , configuraría una página de proyecto para mi juego, de lo contrario alojaría un blog de WordPress / Jekyll o algo similar y escribiría mis publicaciones con eso.
¡Esto te mantendrá motivado y tendrá un lugar para referir a posibles jugadores / evaluadores!
7. Únete a concursos
Hay muchos concursos de desarrollo de juegos que ocurren casi todo el tiempo. Intentaría unirme a uno de estos con mi juego si las reglas lo permiten. Esto aumenta la motivación y hace que todo sea aún más divertido, ¡a quién no le gusta ganar!
(Si está desarrollando bajo un plazo estricto, puede omitir este punto al menos).
fuente
Sugeriría encarecidamente utilizar un sistema de control de versiones, incluso si trabaja solo. Puede ahorrarle mucho tiempo, una vez que borre accidentalmente algo o realice un cambio mayor, solo para darse cuenta más tarde de que fue una mala idea y que tiene que deshacer todos los cambios.
Editar : hay muchas soluciones de control de código fuente gratuitas.
He usado el servidor VisualSVN , que es fácil de configurar y usar en Windows.
También hay alternativas en línea como Codeplex (con
SVNoMercurial), SourceForge o Google Code . Lo bueno es que no tiene que configurar y mantener un repositorio y sus datos están en la nube; El problema es que no puedes alojar libremente proyectos de código cerrado.En cuanto al seguimiento de errores y funciones: si ya tiene un público más amplio que podría estar interesado en probar beta su juego, informar errores y solicitar funciones, continúe.
Sin embargo, si solo hay un puñado de esas personas (o ninguna), es innecesario.
Y en cuanto a las prioridades de desarrollo, eso debe decidirlo usted . ¿Quién debería saber mejor qué hacer en un proyecto que su único desarrollador?
fuente
Creo que sí. Es bastante trivial de configurar y he tenido muchas veces que me he vuelto loco con la refactorización o he hecho algo estúpido y la capacidad de revertir mis cambios me ha ahorrado toneladas de tiempo. Además, si está alojado en un servidor, entonces tiene una copia de seguridad de nuestro código en caso de que algo salga mal .
No creo que sea necesario. Sin embargo, mantendría una lista escrita de lo que tiene intención de hacer para asegurarse de no olvidar un error menor, además, creo que lo ayuda a comenzar nuevamente después de tomar un descanso de la codificación.
Tome esa lista de arriba, cierre los ojos y aliéntela al azar. Trabaja en cualquier característica en la que esté tu dedo. A menos que los elementos dependan unos de otros, es más importante mantener el flujo en marcha que asegurarse de que las cosas sucedan en un orden particular.
fuente
Definitivamente use el control de versiones
El control de versiones es como una red de seguridad para un equilibrista: te libera para intentar locuras. Un gran refactor que elimine grandes fragmentos de código no es un problema si puede revertirlo fácilmente. Es aún menos si está en una rama experimental en su repositorio y puede decidir no fusionarlo nuevamente.
Si no tiene este tipo de libertad, es probable que deje código comentado en todas partes por temor a que lo necesite.
Yo votaría por Git. La sintaxis es un poco extraña, pero dos grandes cosas al respecto son:
git inity estará listo para comenzar a registrar las cosas. Si decide que no desea controlar la versión después de todo,rm -rf .giten esa carpeta ya no es un repositorio de Git.Distribuido a través de SSH . Git se distribuye, lo que significa que puede tener múltiples copias completas de su repositorio (todo el historial, etc.) en varios lugares y mantenerlas sincronizadas. Puede configurar otro repositorio de Git en cualquier máquina donde tenga acceso SSH, luego agregar ese otro repositorio como control remoto. Después de eso, cada vez que desee hacer una copia de seguridad solo
git pusha ese repositorio.Esa es una gran ventaja sobre, por ejemplo, Subversion, donde todo el repositorio vive en una máquina y esa máquina tiene que estar ejecutando un servidor Subversion.
Mercurial puede tener estos mismos puntos a su favor, pero no lo he usado.
fuente
¡Si! Como usted pregunta, supongo que está bien adoptado con el sistema de control de revisiones. ¡Es un deber!
Con respecto a su segunda pregunta, hay un método formal para registrar errores y debe usarlo. Para las funciones de planificación, creo que tomar cualquier ruta menos formal no va a doler (cuando trabajas solo)
Haz esas características primero que harán que tu juego cobre vida. Da una idea de cómo será el juego final.
fuente
1) Sí, por supuesto. Recomiendo Mercurial a través de BitBucket y TortoiseHg. BitBucket es gratuito para hasta 5 usuarios y, dado que está alojado en la nube, le agrega cierta tranquilidad (sin necesidad de copias de seguridad).
2) Se deben corregir los errores antes de implementar nuevas funciones. Usaría una lista TODO accesible simple para rastrear cosas: pendiente / hecho. Puede usar un archivo de texto sin formato, pero no olvide agregarlo a su repositorio de control de código fuente.
3) Haz lo que quieras hacer en un día determinado, teniendo en cuenta que entregar algo jugable por el usuario final es un objetivo principal. Por ejemplo, si está cansado de hacer la física correctamente, trabaje en el renderizado o quizás agregue algunas pruebas unitarias faltantes para esa IA.
Los trozos de trabajo deben ser lo suficientemente pequeños como para hacerse en un par de días. Es crucial mantenerse motivado y evitar el agotamiento.
Si la arquitectura se realiza correctamente, debería poder agregar y modificar fácilmente partes del motor / juego sin afectar a otras múltiples (de lo contrario, comience con algunas refactorizaciones :).
fuente
1) Como todos dicen: SÍ (incluso diría, alquilar uno barato en línea)
2) Mantenga una lista simple o si su proyecto crece y obtiene beta testers, instale Mantis Bug Tracker
3) No lo sé, pero le diré cómo lo estoy haciendo: primero desarrolle las cosas menos interesantes y / o más difíciles. Repita hasta que todo esté hecho. De esa forma, el desarrollo se vuelve más divertido y fácil (y no se enfrentará a ese problema que no puede resolver demasiado tarde si eso ocurriera).
fuente
Gracias por hacer esta pregunta. Esto es exactamente lo que estoy haciendo actualmente.
1) Control de versiones: es imprescindible. En este momento, estoy manteniendo una copia de seguridad manual. Es útil al menos cuando algo que funcionaba bien tenía errores repentinos (o no funcionaba como se esperaba). Comparo versiones y a menudo encuentro errores tontos (principalmente comentando algo)
2) Creé un documento de Word y enumeré todas las características que tendrá mi juego en un orden categórico y con sangrías de varios niveles que enumeran las características secundarias (y las relacionadas con el cliente / servidor o lo que sea aplicable).
3) Después de la lista que obtuve (que no suele estar completa, siempre se agrega algo) Pienso en el flujo de mi juego y resalto todos los puntos que son necesarios para que el juego funcione y empiece a hacerlos. Marco amarillo que significa trabajo en progreso. verde cuando se completa. naranja para indicar que debe mejorarse o tiene algunos errores conocidos
espero que esto ayude
fuente
1.) Vale la pena usar el control de versiones para cualquier proyecto. Incluso los más pequeños si ya sabes cómo usar uno. He usado Subversion durante años en Linux y Windows con TortoiseSVN . Incluso cuando haga un proyecto pequeño (<500 líneas), crearé un repositorio para poder deshacer los cambios, rastrear lo que estaba haciendo si abandono el proyecto por un tiempo, etc.
2.) Depende de qué tan grande será el proyecto. Si planeas hacer una prueba de juego con un equipo y distribuir, probablemente valga la pena tener un sistema de seguimiento de errores. Actualmente estoy trabajando solo (aunque tengo un artista) en un proyecto que tiene más de 20k líneas, y solo mantengo mi lista de tareas en un archivo de texto que también está en mi repositorio SVN. Aunque todavía no tengo la necesidad de compartirlo con otros, por lo tanto, no tener un seguimiento de errores se ajusta a mis necesidades por ahora. No me preocuparía hasta que haya una necesidad. Lo peor que puede suceder es que tendrá que ingresar los errores que ya haya escrito y eliminar / revisar los que corrigió. Cuando comience a perder la pista mental de sus notas, obtenga un rastreador de errores.
3.) Trazarlo en papel. Comience con lo que desea que sea su juego terminado, escriba la esencia del mismo. Luego, divídalo en lo que se necesitará para hacerlo: ¿detección de colisión? código de red? tipos de jugadores y monstruos? jerarquías de clase? Trabaje hacia atrás desde su visión para tener una idea clara de cómo construirlo desde cero. Supongo que estás usando un lenguaje orientado a objetos. El paso más crucial para comenzar sería establecer esas jerarquías de clase de manera sensata. Haga todo lo posible por no tener absolutamente ninguna herencia múltiple (aunque a veces es inevitable), trace las relaciones de clase en un editor de diagramas (uso Dia ), etc. Los principios básicos ayudan mucho a evitar dolores de cabeza más adelante.
fuente