Quel type de gestion de projet un développeur solo doit-il utiliser?

Je travaille seul sur un projet de jeu dont le développement pourrait être séparé en 3 parties indépendantes (génération de la carte, le moteur "overworld" et le moteur de combat), mais au fur et à mesure que le développement progresse, je ne suis pas sûr de la manière dont je devrais traiter la gestion de ce projet, notamment en ce qui concerne ces 3 points:

1. Vaut-il la peine d’utiliser un système de contrôle de version, puisque je travaille en solo?

2. Devrais-je utiliser une méthode formelle pour enregistrer les fonctionnalités / bugs planifiés (je ne me souviens que de ce qu'il faut faire pour l'instant)

3. La question la plus importante: comment savoir ce qu'il faut développer en premier? Maintenant que les bases sont terminées, je connais la liste des fonctionnalités à coder, mais je ne sais pas dans quel ordre je devrais le faire.

J'utiliserais:

1. Gestion du code

GIT (et la référence géniale ), un gestionnaire de code source distribué, permettant de gérer mon code, et de l'héberger sur GitHub en tant que projet privé si je souhaite le garder au maximum.

(Il y a beaucoup d'options ici, juste Google pour la gestion du code source, vous n'avez même pas besoin d'utiliser GitHub ou tout autre site Web, Git fonctionnera parfaitement sur votre ordinateur local, mais utiliser GitHub rendra la gestion de sauvegarde plus difficile. beaucoup plus facile.

Si vous avez deux ordinateurs, vous pouvez créer un référentiel sur celui que vous appelez votre ordinateur de sauvegarde, puis vous clonez ce référentiel sur le réseau local et vous l'utilisez pour le développement. Lorsque vous avez terminé avec une fonctionnalité, vous pouvez la pousser vers le machine de sauvegarde et vous aurez une sauvegarde 1: 1!)

2. Gestion des problèmes et des fonctionnalités

J'utiliserais la gestion intégrée des problèmes de Trello ou de GitHub pour suivre les bogues et les tâches à effectuer.

3. Avoir un processus de conception

Je concevrais d'abord mon jeu;

1. d'abord dans mon esprit,
2. puis sur papier,
3. Ensuite, utilisez probablement GameMaker ou PyGame pour prototyper mon idée et effectuez une itération de 1 à 3 jusqu'à ce que j'ai quelque chose que j'aime jouer.

4. Utiliser mon prototype comme guide et développer mon jeu

Ensuite, je mettrais mon prototype de côté et choisirais une plate-forme pour laquelle je souhaite développer. Recherchez ensuite les moteurs existants et choisissez celui qui convient le mieux à mon idée de jeu. Ensuite, je fixais des objectifs clairs pour mon projet, les structurais en petites tâches, puis commençais à travailler pour les achever. Lorsque vous aurez atteint cet état, vous constaterez probablement que vous avez votre propre façon de travailler qui vous convient le mieux, alors allez-y!

Il existe différentes méthodologies / philosophies que vous pouvez appliquer à votre style de développement, XP, Waterfall, etc. Adoptez celle qui vous fait progresser le plus rapidement.

5. Avoir beaucoup de testeurs de jeux!

Lorsque vous avez quelque chose de jouable, demandez à vos amis immédiats de l'essayer! Facilitez-leur la tâche en vous aidant en configurant des packages d'installation rapide s'ils exécutent Windows ou en écrivant un script shell qui puisse automatiser le processus s'ils utilisent Linux / Mac. Faites très attention aux commentaires de vos testeurs et n'oubliez pas de les informer sur la conception de votre jeu et sur le type de jeu que vous essayez de créer.

6. Faire un site web pour mon jeu

Dès que quelque chose se passe bien, je créerais probablement un site Web pour mon jeu - pour laisser libre cours à ma créativité et à mon contenu lorsqu'il ne peut pas être appliqué à la progression de mon jeu, par exemple, si je me concentre sur mes études. ou besoin d'une pause de développement!

Si j'utilise GitHub , je créerais une page de projet pour mon jeu, sinon j'hébergerais un blog WordPress / Jekyll ou quelque chose de similaire et j'écrirais mes articles avec ça.

Cela vous permettra de rester motivé tout en ayant un endroit où référer des joueurs / testeurs potentiels!

7. Participer aux concours

Il y a beaucoup de concours de développeurs de jeux qui se déroulent presque tout le temps. J'essaierais de rejoindre l'un d'eux avec mon jeu si les règles le permettent. Cela augmente la motivation et rend tout encore plus amusant - qui n'aime pas gagner!

(Si vous développez dans des délais très stricts, vous pouvez au moins ignorer ce point.)

Je suggérerais fortement d'utiliser un système de contrôle de version, même si vous travaillez seul. Cela peut vous faire gagner beaucoup de temps, si vous supprimez accidentellement quelque chose ou effectuez un changement plus important, pour vous rendre compte plus tard que c'était une mauvaise idée et que vous devez annuler les modifications.

Edit : Il existe de nombreuses solutions de contrôle de source gratuites.

• J'ai utilisé le serveur VisualSVN , qui est facile à configurer et à utiliser sous Windows.

• Il existe également des alternatives en ligne comme Codeplex (avec SVNou Mercurial), SourceForge ou Google Code . L'avantage est que vous n'avez pas besoin de configurer et de gérer un référentiel et que vos données sont dans le cloud; Le problème, c'est que vous ne pouvez pas héberger librement des projets à source fermée.

En ce qui concerne le suivi des bogues et des fonctionnalités: si vous avez déjà un public plus large qui pourrait être intéressé par le test bêta de votre jeu, le signalement de bugs et la demande de fonctionnalités, continuez.
Si, cependant, il n'y a qu'une poignée de personnes (ou aucune), c'est inutile.

Et en ce qui concerne les priorités de développement - à vous de décider. Qui devrait savoir mieux quoi faire dans un projet que son seul développeur?

Vaut-il la peine d’utiliser un système de contrôle de version, puisque je travaille en solo?

Je le pense. C'est assez simple à configurer et plusieurs fois je suis devenu fou avec le refactoring ou j'ai fait autre chose de stupide et la possibilité d'annuler mes modifications a permis de gagner beaucoup de temps. De plus, si elle est hébergée sur un serveur, vous avez une copie de sauvegarde de notre code en cas de problème .

Devrais-je utiliser une méthode formelle pour enregistrer les fonctionnalités / bugs planifiés (je ne me souviens que de ce qu'il faut faire pour l'instant)

Je ne pense pas que ce soit nécessaire. Je garderais une liste écrite de ce que vous avez l'intention de faire, juste pour vous assurer de ne pas oublier un bug mineur. De plus, je trouve que cela vous aide à redémarrer après une pause dans le codage.

La question la plus importante: comment savoir ce qu'il faut développer en premier? Maintenant que les bases sont terminées, je connais la liste des fonctionnalités à coder, mais je ne sais pas dans quel ordre je devrais le faire.

Prenez cette liste ci-dessus, fermez les yeux et piquez-la au hasard. Travaillez sur la fonction que vous avez sélectionnée. À moins que les articles dépendent les uns des autres, il est plus important de maintenir le flux que de s'assurer que les choses se passent dans un ordre particulier.

Utilisez certainement le contrôle de version

Le contrôle de version est comme un filet de sécurité pour le funambule: il vous permet de tenter des choses folles. Un grand refactor supprimant d’énormes morceaux de code n’est pas un problème si vous pouvez facilement revenir en arrière. C'est encore moins le cas si vous êtes sur une branche expérimentale de votre repo et que vous pouvez décider de ne pas le fusionner.

Si vous ne disposez pas de ce type de liberté, vous risquez de laisser le code commenté en suspens partout, de peur que vous n'en ayez besoin.

Je mettrais un vote pour Git. La syntaxe est un peu étrange, mais elle présente deux avantages:

• Frais généraux bas . Placez-vous dans un dossier et saisissez git init-le. Vous êtes prêt à commencer à archiver des éléments. Si vous décidez que vous ne souhaitez pas contrôler la version, vous ne le contrôlerez rm -rf .gitplus.

• Distribué via SSH . Git est distribué, ce qui signifie que vous pouvez avoir plusieurs copies complètes de votre repo (toute l'histoire, etc.) à différents endroits et les synchroniser. Vous pouvez configurer un autre référentiel Git sur toute machine sur laquelle vous avez un accès SSH, puis ajouter cet autre référentiel en tant que télécommande. Après cela, chaque fois que vous souhaitez sauvegarder uniquement git pushsur ce dépôt.

  C'est un gros avantage par rapport à, par exemple, Subversion, où tout le référentiel réside sur une seule machine et que cette machine doit exécuter un serveur Subversion.

Mercurial a peut-être les mêmes arguments en sa faveur, mais je ne l'ai pas utilisé.

1. Oui! Puisque vous demandez, je suppose que vous êtes bien adopté avec le système de contrôle de révision. C'est un impératif!

2. En ce qui concerne votre deuxième question, il existe une méthode formelle d’enregistrement des bogues et vous devriez l’utiliser. Pour les fonctionnalités de planification, je pense que prendre un itinéraire moins formel ne me fera pas mal (lorsque vous travaillez seul)

3. Faites d'abord ces fonctionnalités qui donneront vie à votre jeu. Donnez une idée de la façon dont le jeu final sera.

1) Oui bien sûr. Je recommande Mercurial via BitBucket et TortoiseHg. BitBucket est gratuit pour un maximum de 5 utilisateurs et, comme il est hébergé dans le cloud, cela vous donne un peu de l'esprit (pas besoin de sauvegardes).

2) Les bugs doivent être corrigés avant de mettre en place de nouvelles fonctionnalités. J'utiliserais une simple liste de TODO accessible pour suivre les choses en attente / terminées. Vous pouvez simplement utiliser un fichier texte brut, mais n'oubliez pas de l'ajouter à votre référentiel de contrôle de source.

3) Faites ce que vous voulez faire chaque jour, tout en gardant à l'esprit que fournir quelque chose qui peut être lu par l'utilisateur final est un objectif primordial. Par exemple, si vous êtes fatigué de maîtriser la physique, travaillez sur le rendu ou ajoutez éventuellement des tests unitaires manquants pour cette IA.

Des morceaux de travail devraient être assez petits pour être faits dans environ deux jours. Il est essentiel de rester motivé et d'éviter l'épuisement professionnel.

Si l'architecture est faite correctement, vous devriez pouvoir ajouter facilement des parties de modification du moteur / jeu sans en affecter plusieurs autres (sinon, commencez par un refactoring :).

1) Comme tout le monde le dit: OUI (je dirais même, louez-en un pas cher en ligne)

2) Gardez une liste simple ou si votre projet grossit et que vous obtenez des bêta-testeurs, installez Mantis Bug Tracker

3) Je ne sais pas, mais je vais vous dire comment je le fais: Développez d’abord les choses les moins intéressantes et / ou les plus difficiles. Répétez jusqu'à ce que tout soit terminé. De cette façon, le développement devient simplement plus amusant et plus facile (et vous ne rencontrerez pas ce problème que vous ne pouvez pas résoudre trop tard si cela se produisait).

Merci d'avoir posé cette question. C'est exactement ce que je fais actuellement.

1) Contrôle de version: C'est indispensable. En ce moment, je maintiens une sauvegarde manuelle. Il est utile au moins lorsque quelque chose qui fonctionnait bien a des erreurs de projection (ou ne fonctionne pas comme prévu). Je compare les versions et trouve souvent des erreurs stupides (surtout commentant quelque chose)

2) J'ai créé un document Word et répertorié toutes les fonctionnalités de mon jeu dans un ordre catégorique et avec des retraits sur plusieurs niveaux, répertoriant les sous-fonctionnalités (et les fonctions client / serveur ou ce qui est applicable).

3) Après la liste que j’ai obtenue (qui ne sera pas complète, j’ai toujours quelque chose à ajouter), je pense à mon déroulement du jeu et jette la lumière sur tous les points nécessaires pour que je puisse faire fonctionner le jeu et commencer à le faire. Je marque jaune signifiant travail en cours. vert une fois terminé. orange pour indiquer l’amélioration ou a quelques bugs connus

J'espère que cela t'aides

1.) Il est utile d’utiliser le contrôle de version pour tout projet. Même les plus petits, si vous savez déjà en utiliser un. J'ai utilisé Subversion pendant des années sur Linux et Windows avec TortoiseSVN . Même lors de la création d'un petit projet (<500 lignes), je vais créer un référentiel pour pouvoir annuler les modifications, suivre ce que je faisais si j'abandonnais le projet pendant un certain temps, etc.

2.) Cela dépend de la taille du projet. Si vous envisagez de jouer avec une équipe et de la distribuer, il est probablement utile de disposer d'un système de suivi des bogues. Je travaille actuellement en solo (bien que j'aie un artiste) sur un projet de plus de 20 000 lignes et je conserve ma liste de tâches dans un fichier texte qui se trouve également dans mon référentiel SVN. Bien que je n'ai pas exactement besoin de le partager avec les autres pour l'instant, ne pas avoir de suivi de bogues correspond à mes besoins pour l'instant. Je ne m'inquiéterais pas jusqu'à ce qu'il y ait un besoin. Le pire qui puisse arriver est de devoir entrer les bogues que vous avez déjà écrits et supprimer / réviser ceux que vous avez corrigés. Lorsque vous commencez à perdre la trace mentale de vos notes, procurez-vous un outil de suivi des bogues.

3.) Tracez-le sur du papier. Commencez par ce que vous voulez que votre jeu fini soit, écrivez l'essentiel de celui-ci. Puis décomposez-le en ce qu’il faudra pour que cela se produise: détection de collision? code de réseau? types de joueurs et de monstres? hiérarchies de classes? Travaillez à rebours par rapport à votre vision pour avoir une idée claire de la manière de la construire à partir de la base. Je suppose que vous utilisez un langage orienté objet. L’étape la plus cruciale pour commencer serait de mettre en place ces hiérarchies de classes de manière sensée. Essayez de ne plus avoir d'héritage multiple (bien que cela soit parfois inévitable), tracez les relations de classe dans un éditeur de diagramme (j'utilise Dia ), etc.