Solarlune: Ce que j’aurais aimé qu’on me dise avant de sortir mon premier jeu vidéo

Solar­lune, c’est un développeur qui m’a pas mal inspiré pour mon pre­mier livre sur Blender. En févri­er 2020, il a pub­lié son pre­mier jeu “com­mer­cial” sous Steam: Bloody Ral­ly Show. Le jeu a été réal­isé sous Uni­ty, sur son temps libre. Esti­mant avoir fait de nom­breuses erreurs, il a sor­ti une vidéo dans laque­lle il s’est exprimé à ce sujet. Voici une petite tra­duc­tion rapi­de de ce qu’il nous con­fie, c’est-à-dire, la liste de tout ce qu’il aurait aimé que quelqu’un lui dise avant de com­mencer à tra­vailler sur son pre­mier jeu. De bons con­seils pour créer un jeu vidéo.

Solarlune : Introduction

Hé gamede­vs!  Au cours des deux dernières années, j’ai réal­isé un pro­jet de jeu sur mon temps livre que j’ai sor­ti sur Steam il y a quelques mois. J’ai fait beau­coup d’er­reurs tout au long du proces­sus de développe­ment et je tenais une liste de notes pour mon «moi passé». Cette liste peut ne pas s’ap­pli­quer à votre jeu en par­ti­c­uli­er, ni à votre moteur / lan­gage (j’u­til­i­sais Uni­ty / C #), mais je crois que quelqu’un pour­rait trou­ver une ou deux choses ici qui l’aidera, alors je vais partager.

Les 60 conseils pour créer un jeu vidéo 

Ce que j’aimerais que quelqu’un me dise quand j’ai com­mencé à tra­vailler sur mon jeu:

  1. Faire un jeu com­plexe et raf­finé qui mérite d’être pub­lié et qui a même une faible chance de suc­cès sera 100 fois plus dif­fi­cile que vous ne l’au­riez jamais imag­iné. Je ne saurais trop insis­ter sur ce point.
  2. Utilisez l’échelle d’u­nité cor­recte dès le début, surtout si vous avez de la physique dans le jeu. Dans Uni­ty, 1 unité = 1 mètre. Ne pas définir l’échelle cor­recte ren­dra votre physique bizarre.
  3. Les sprites doivent être créés et importés avec une taille / DPI / PPU cohérente
  4. Assurez-vous que les sprites sont soit POT (Pow­er of 2: 32x32,64x64,128x128,etc.), ou emballez-les dans des atlas
  5. Activez la com­pres­sion crunch sur tous les sprites que vous pou­vez (POT + crunch peut facile­ment trans­former 1,3 Mo en 20 Ko)
  6. Créez votre inter­face util­isa­teur à par­tir de com­posants réutilisables
  7. Nom­mez vos com­posants d’in­ter­face util­isa­teur réu­til­is­ables de manière cohérente afin qu’ils soient faciles à trouver
  8. Avoir un doc­u­ment de guide de style dès le début
  9. Utilisez des espaces de noms en C # et divisez votre code en assem­blys dès le début. Cela impose une archi­tec­ture plus dis­tincte­ment séparée et réduit les temps de com­pi­la­tion à long terme.
  10. N’u­tilisez jamais de mag­ic strings ni même de string con­stants. Si vous utilisez des chaînes iden­ti­fi­er un objet, arrêtez. Utilisez des enums.
  11. Préférez des ses­sions plus longues que mul­ti­pli­er les ses­sions. 2 heures sont bien plus pro­duc­tives que 4 ses­sions dis­tinctes de 30 minutes
  12. Le Design ne doit pas faire par­tie d’un pro­to­type. N’es­sayez pas de le ren­dre joli, vous devrez le jeter de toute façon.
  13. Ne perdez pas de temps à créer de “l’art façon développeurs”. Si vous savez que cela ressem­blera tou­jours à de la merde, peu importe vos efforts, con­cen­trez-vous plutôt sur ce que vous savez faire de mieux. Vous achèterez plus tard des assets ou trou­verez quelqu’un qui se join­dra à l’équipe et le fera pour vous (et mieux).
  14. Évitez les pub­lic sta­t­ic en C#.
  15. Essayez de faire moins de POO, surtout si vous n’êtes pas trop bon dans ce domaine. Gardez les choses isolées. Avoir moins d’é­tat. Échangez des don­nées, pas des objets avec des états et des hiérar­chies. Greg: Je ne suis pas d’ac­cord, mais en même temps, je fais de la POO depuis longtemps. J’u­tilise pour ma part mas­sive­ment la POO (sous UE4, c’est un peu nor­mal) et ce qui est com­mun à plusieurs class­es, j’u­tilise des composants.
  16. Évitez les grandes class­es et les méth­odes à tout prix. Séparez par respon­s­abil­ités et faites-le tôt. 300 lignes, c’est prob­a­ble­ment trop pour une classe, 30 lignes, c’est trop pour une seule méth­ode. Split split split.
  17. Organ­isez les illus­tra­tions de la même manière que vous organ­isez le code. Il doit être claire­ment et logique­ment séparé, espacé et avoir une con­ven­tion de dénomination.
  18. Ne vous con­tentez pas de copi­er et de mod­i­fi­er légère­ment le code de vos autres jeux, con­stru­isez-vous une bib­lio­thèque partagée de choses atom­iques qui peu­vent ensuite être util­isées dans vos autres jeux.
  19. Si vous utilisez des Script­ableOb­jects, ils peu­vent être facile­ment séri­al­isés en JSON. Ceci est utile pour activ­er le modding.
  20. Pensez à per­me­t­tre le mod­ding le plus tôt. Présen­tez l’ar­chi­tec­ture noy­au du jeu ini­tial de manière à pou­voir créer vous-même votre jeu prin­ci­pal en tant que mod ou ensem­ble de mods. Le con­tenu du jeu doit être une archi­tec­ture «douce», il doit être facile­ment mod­i­fi­able et enfichable.
  21. Si vous prévoyez d’avoir un mul­ti­joueur en ligne, com­mencez à con­stru­ire le jeu avec lui dès le pre­mier jour. En fonc­tion du type de jeu et de votre code, le mul­ti­joueur au som­met d’un pro­jet presque ter­miné sera très dif­fi­cile à presque impossible.
  22. Ne pro­posez pas de pre­mières ver­sions inachevées de votre jeu aux stream­ers et aux créa­teurs de con­tenu. Ces vidéos de votre jeu man­quant de con­tenu, merdique vous hanteront très longtemps. Greg: Je ne suis pas cer­tain. Oui, il ne faut pas partager si c’est mau­vais, mais il faut aus­si com­mu­ni­quer le plus tôt pos­si­ble, donc à vous de juger.
  23. Développez une com­mu­nauté sur Dis­cord et Reddit.
  24. Créez des ver­sions pour tous les sys­tèmes d’ex­ploita­tion (Win, Lin­ux, Mac) et téléchargez-les sur Steam en une seule opéra­tion. Vous pou­vez créer pour Lin­ux et Mac à par­tir de Win­dows avec Unity.
  25. Arrêtez de tester votre jeu après chaque change­ment, ou de livr­er des builds avec des bugs à votre com­mu­nauté. Écrire des tests d’in­té­gra­tion (selon l’outil) pour automa­tis­er les tests. Les tests peu­vent jouer à votre jeu à une vitesse 100x et détecter les plan­tages et les erreurs pen­dant que vous vous con­cen­trez sur des choses plus importantes.
  26. Nom­mez vos GameOb­jects de la même manière que vous nom­mez vos class­es MonoBe­hav­iour. Ou au moins faire une con­ven­tion de dénom­i­na­tion cohérente, il sera donc triv­ial de trou­ver un objet de jeu par le nom de la classe de com­porte­ment. Oui, vous pou­vez égale­ment utilis­er la recherche, mais une hiérar­chie d’ob­jet de jeu bien nom­mée est bien meilleure. Vous pou­vez égale­ment renom­mer les objets de jeu lors de l’exé­cu­tion à par­tir de scripts, et vous devriez, si vous instan­ciez des préfabriqués.
  27. Créez-vous un sys­tème d’in­ter­face util­isa­teur solide à l’a­vance, puis utilisez-le pour con­stru­ire le jeu entier. Il est dif­fi­cile de créer une inter­face util­isa­teur solide et flexible.
  28. Ne câblez jamais vos bou­tons d’in­ter­face util­isa­teur via Uni­ty Edi­tor, utilisez plutôt onClick.AddListener à par­tir du code.
  29. Essayez d’avoir autant que pos­si­ble de “defined” dans le code, plutôt que de compter sur Uni­ty Edi­tor ou les pre­fab seri­al­iza­tion. Les fichiers uni­taires YAML vous fer­ont pass­er un mau­vais moment. Utilisez l’édi­teur pour trou­ver rapi­de­ment un bon ensem­ble de valeurs lors de l’exé­cu­tion, puis met­tez-le dans le code et sup­primez [Seri­al­ize­Field].
  30. N’u­tilisez pas de vari­ables publiques, si vous devez expos­er une vari­able privée à Uni­ty Edi­tor, utilisez [Seri­al­ize­Field]
  31. Soyez super cohérent dans la dénom­i­na­tion et l’or­gan­i­sa­tion du code.
  32. Ne prenez pas de rac­cour­cis, ou ne faites pas de com­pro­mis sur les par­ties les plus impor­tantes et les plus dif­fi­ciles de votre jeu — mécanique de base, généra­tion procé­du­rale, inputs des joueurs (s’ils sont com­plex­es), etc. Vous le regret­terez plus tard. En prenant des rac­cour­cis, en bâclant le code, copi­er-coller quelques trucs plusieurs fois, écrire une longue méth­ode avec beau­coup d’in­struc­tions if, etc. Tout cela vous coutera fort quand vous devrez refac­toris­er. Et si vous ne le faites pas,il sera dif­fi­cile de chang­er quoi que ce soit par la suite.
  33. Réfléchissez bien avant de définir un nom défini­tif pour votre jeu. Prenez le temps de la réfléx­ion, une semaine ou deux. Le renom­mer plus tard peut facile­ment devenir un véri­ta­ble cauchemar.
  34. Nom­mez très tôt votre pro­jet avec un pro­to­type de nom de code générique. Ne com­mencez pas par le nom­mer, acheter des domaines, con­fig­ur­er des comptes, acheter une appli­ca­tion Steam, etc. Tout cela peut être fait bien plus tard. Greg: Bon, ok, mais je le répète, il faut com­mu­ni­quer le plus tôt pos­si­ble, alors c’est délicat.
  35. Lorsque vous effectuez une généra­tion procé­du­rale, visu­alisez chaque étape du proces­sus de généra­tion pour le com­pren­dre et le véri­fi­er. Si vous faites des hypothès­es sur le déroule­ment de l’une des étapes, les bogues et les erreurs dans ces étapes de généra­tion vont tout gâch­er, et ce sera un cauchemar de déboguer sans visualisation.
  36. Définis­sez les polices TextMesh­Pro par défaut et de sec­ours dès le début.
  37. N’u­tilisez pas iTween. Utilisez LeanTween ou une autre solu­tion performante.
  38. Évitez la physique Uni­ty 2D même pour les jeux 2D. Con­stru­isez-le en 3D, vous obtien­drez un Nvidia Physx mul­ti-thread au lieu de Box2D beau­coup moins per­for­mant. Greg: Sous Unre­al, la ques­tion ne se pose même pas, puisque le moteur de physique 2D a été retiré de mémoire…
  39. Utilisez Debug.Break () pour attrap­er des erreurs bizarres et les analyser. Fonc­tionne très bien en com­bi­nai­son avec des tests. Il existe égale­ment “Error Pause” dans la con­sole qui le fait en cas d’erreur.
  40. Faites des builds aus­si vite que pos­si­ble. Investis­sez du temps pour com­pren­dre où vos builds pren­nent le plus de temps… et vous vous épargnerez beau­coup de temps à long terme. Par exem­ple, vous n’avez pas besoin de com­pil­er des vari­antes de shad­er 32K à chaque build. Utilisez des shaders préchargés pour obtenir une accéléra­tion sig­ni­fica­tive (Edit > Project Set­tings > Graph­ics > Shad­er Loading).
  41. Trans­formez tous vos élé­ments d’in­ter­face util­isa­teur en pre­fabs. Il a quelques bizarreries, comme l’or­dre des élé­ments avec Lay­out­Group, mais il existe des solu­tions de contournement.
  42. Évitez Lay­out­Group et tout ce qui déclenche la recon­struc­tion de Can­vas, en par­ti­c­uli­er dans la méth­ode Update, surtout si vous prévoyez de porter votre jeu sur des consoles.
  43. Nest­ed Pre­fab, c’est top !
  44. Com­mencez à créer votre jeu avec la dernière ver­sion bêta d’U­ni­ty. Au moment où vous aurez ter­miné, cette ver­sion bêta sera sta­ble et obsolète. Greg: Mouais… Vous pour­riez aus­si tomber sur des soucis qui n’au­ront pas de réponse avant longtems… Il y a par­fois des régres­sions blo­quantes. Et sous UE4, je vous décon­seille forte­ment à cause des plu­g­ins qui ne seront pas compatibles.
  45. Essayez tou­jours d’u­tilis­er la dernière unité sta­ble à la fin de votre projet.
  46. Les assets du mag­a­sin doivent être appelés pas­sifs. Moins vous utilisez, moins vous aurez de prob­lèmes. Greg: C’est peut-être vrai pour Uni­ty, mais j’es­time que ce n’est pas le cas sous UE4. On gagne beau­coup de temps à utilis­er des assets exis­tants. Lui par­le prob­a­ble­ment surtout de “code” — et là, ça dépend for­cé­ment de votre pro­fil. Par­fois, pren­dre en main un code fait par quelqu’un d’autre, c’est plus long que de l’écrire soi-même… Mais heureuse­ment, ce n’est pas tou­jours le cas.
  47. Faites un usage inten­sif de Uni­ty Crash Report­ing. Vous n’avez pas besoin de deman­der aux gens de vous envoy­er des jour­naux en cas de prob­lème. Deman­dez sim­ple­ment leur mod­èle de carte OS / Graph­ics et trou­vez les rap­ports de plan­tage avec les jour­naux dans le tableau de bord en ligne.
  48. Aug­mentez la ver­sion de votre appli­ca­tion à chaque fois que vous effectuez une généra­tion. Cela devrait être fait automa­tique­ment. Très utile lorsqu’il est com­biné avec Uni­ty Crash Report­ing, car vous saurez si vos nou­velles ver­sions obti­en­nent d’an­ciens prob­lèmes que vous pensez avoir cor­rigés, etc. Et lorsque quelque chose provient d’une anci­enne ver­sion, vous saurez que ce ne sont pas vos util­isa­teurs payants, mais un pirate avec une anci­enne copie du jeu. Si vous ne ren­seignez jamais votre ver­sion, ce sera un cauchemar à suivre.
  49. Une inter­face util­isa­teur dynamique sophis­tiquée n’en vaut pas la peine. Ren­dez l’in­ter­face util­isa­teur sim­ple et sim­ple à con­stru­ire. Elle doit être con­viviale pour le joueur. N’u­tilisez jamais de dis­po­si­tions diag­o­nales à moins que vous ne vouliez souf­frir le martyr.
  50. Si vous con­stru­isez un jeu où l’IA utilis­era un con­trôleur PID (joy­stick virtuel), com­mencez par faire vos inputs, et seule­ment après, tra­vaillez sur l’IA, ou vous devrez la réécrire à chaque fois que votre physique / manip­u­la­tion du jeu changent.
  51. Utilisez un édi­teur de code qui affiche des références sur les class­es, les vari­ables et les méth­odes. Visu­al Stu­dio Code est génial, il fait cela, et cette fonc­tion­nal­ité par­ti­c­ulière est cru­ciale pour nav­iguer dans votre code de jeu lorsqu’il grandit. Greg: Intel­lisense quoi.
  52. Beau­coup d’ex­em­ples de code qui peu­vent être trou­vés en ligne sont absol­u­ment hor­ri­bles. Ils peu­vent être réécrits pour être beau­coup plus courts et / ou plus per­for­mants. Un exem­ple notable — Steamworks.NET
  53. Les excep­tions non inter­cep­tées dans les corou­tines Uni­ty entraî­nent des plan­tages impos­si­bles à déboguer. Tout ce qui fonc­tionne dans une corou­tine doit être absol­u­ment à l’épreuve des balles. Si une référence peut être nulle, véri­fiez-la, etc. Et vous ne pou­vez pas utilis­er try / catch autour de tout ce qui a un ren­de­ment, alors réfléchissez bien. Divisez les corou­tines en sous-méth­odes, gérez‑y les exceptions.
  54. Con­stru­isez-vous un sys­tème de ges­tion corou­tine. Vous devriez pou­voir savoir quelles corou­tines sont en cours d’exé­cu­tion, pen­dant com­bi­en de temps, etc.
  55. Créez un mode pho­to dans votre jeu dès le début. Vous pour­rez alors faire des gifs, de belles cap­tures d’écran et des trail­ers avec facil­ité. Greg: Sous UE4, les screen­shots sont sup­port­ées via la con­sole, mais on peut aus­si utilis­er Ansel pour faire des screen­shots en très haute réso­lu­tion ou à 360°.
  56. Con­stru­isez-vous très tôt une con­sole développeur. Essay­er les choses rapi­de­ment sans avoir à créer une inter­face util­isa­teur jetable est fan­tas­tique. Et plus tard, vos joueurs peu­vent utilis­er la con­sole pour mod­ding / cheats / etc. Greg: Le mode con­sole est inhérent à Unre­al, il suf­fit d’avoir par exem­ple un event dans un lev­el blue­print pour qu’il soit pos­si­ble de l’ap­pel­er directe­ment via la con­sole, en pré­fix­ant par “ce ” (cus­tom event) pour la recherche.
  57. Ne comptez pas sur Play­er­Prefs. Séri­alisez votre con­fig­u­ra­tion de jeu avec tous les élé­ments réglables dans un for­mat de texte brut.
  58. Ne testez jamais plus d’un change­ment à la fois.
  59. Ne vous lev­ez pas à 4h du matin pour trou­ver le temps de faire votre jeu. Ne craquez pas. Prenez quelques jours de con­gé. Exer­ci­ce. Mangez bien (max­imisez l’ap­port en pro­téines, évitez les glu­cides + les graiss­es, c’est le pire). Ne vous tuez pas pour faire un jeu. Ayez une vie en dehors de votre pas­sion. Greg: Ahah… c’est vrai, mais c’est pas évi­dent à suivre 😉
  60. À moins que vous ne soyez déjà une célébrité avec plus de 10 000 abon­nés, le spam sur votre jeu sur Twit­ter sera une cause per­due. La balise #gamedev se déplace à quelques mes­sages par sec­onde, et très prob­a­ble­ment per­son­ne ne se souciera de votre jeu ou de ce que vous avez fait récem­ment. Con­cen­trez-vous plutôt sur la con­struc­tion d’un meilleur jeu. Greg: Et de super gifs ani­més de Game­play comme vu ici.

Voilà, c’est une liste non-exhaus­tive et assez per­son­nelle de con­seils pour créer un jeu vidéo. En fait, il y a tellem­ment de choses à savoir, et à plein de niveaux, que j’ai l’im­pres­sion qu’on ne fait qu’é­gra­tinier la sur­face. Mais si ça peut servir déjà à d’autres, j’avais envie de le partager avec vous.

Pour finir, je vous laisse avec le trail­er de son jeu qui a l’air sympathique:

2 réflexions sur « Solarlune: Ce que j’aurais aimé qu’on me dise avant de sortir mon premier jeu vidéo »

  1. Salut Benoit. Oui, en effet, c’est assez sub­jec­tif et tout est ouvert à la dis­cus­sion. C’est son ressen­ti, ça donne des pistes 🙂

  2. Liste très intéres­sante, bien que je ne sois pas trop d’ac­cord avec cer­tains points comme toi et que d’autres points ne sont pas vrai­ment justifiés. 😉

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.