Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 10 sur 10
  1. #1
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut Aide pour quelques codages

    Bonjour,

    Je recherche une personne qui serais d'accord pour coder quelques travaux ASM pour un projet de 'remake' du célèbre jeu "Super Metroid" (1994).
    Je suis designer industriel/concepteur (Je ne connais strictement rien en programmations), et j'ai passé 2 années a élaborer quelque chose de cohérent et détaillé .

    En réalité , il y a déjà un grand nombre de petits rigolos qui "bidouillent" sur ce jeu , mais personne ne prends ça au sérieux .
    La ROM a déjà été désassemblée par des programmeurs expérimentés il y à quelques années .
    Il existe donc , pour faciliter le travail , une "RAM map" , et une "Rom map" ; expliquant a quoi sert chaque banques/adresses .
    Ce que je demande est , dans la majeure partie des cas , de réaliser des 'checks', Hi-Jacker des routines ou sub-routines et les repointer
    dans de l'espace libre en fin de banques avec des JMP ou des JSR/JSL , du style :

    Hi-jack pt:
    JMP (espace libre*) + NOPer les octets restants

    *espace libre :
    LDA (une adresse RAM),
    CMP (une valeure)
    BEQ/BNE
    RTS

    Ou BIT/EOR/AND
    pour par exemple tester une adresse , voir si le ou les Bit/s sont 'set' ou 'cleared' , et embrayer sur d'autres branches , etc ...

    Dans les autres cas , ce serais de créer des IA pour quelques ennemies (beaucoup de délais en frames , de positions X/Y en pixels , etc...)
    Avec un premier code exécuté a la première frame d'apparition à l'image (Initiation), et un second qui permet d'etre lu en boucle à partir de la (Running). Bien sur , la majorité des choses a savoir sur les IA existent sur des documents que je possède .

    Les scriptes sont assez simples de ce que j'ai pu voir , mais il existe probablement des interactions divers entre différents types de format de codage/compression , des 'cycles' a respecter , enfin tout une multitude de choses qui font que je n'ai pas le savoir suffisant pour réaliser ces codes par moi meme (Bien que m'y étant intéressé au maximum)...

    Je vous remercie d'avance pour votre éventuelle aide !

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    septembre 2007
    Messages
    5 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 5 226
    Points : 13 084
    Points
    13 084

    Par défaut

    Hello,

    J'ai beaucoup de mal à voir où tu veux en venir. Apparemment, tu veux hacker le code de Super Metroid qui, si je ne m'abuse, fonctionne sur console.

    Première étape : sur quelle machine ?

    Deuxièmement, tu comptes faire un vrai remake ou tu comptes étendre l'existant pour modifier le comportement du jeu actuel ? Parce que dans ce second cas, nos lois font que le désassemblage est à la limite de la légalité, et qu'il est très facile de franchir la ligne rouge.

  3. #3
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Et bien , la plateforme de base est la console Super Nintendo , mais il est parfaitement possible d'y jouer sur ordinateur , avec un émulateur de Super Nintendo (Comme par exemple 'Snes9X'). Le jeu est une ROM codée en ASM x86 16 bits .

    Pour ce que je souhaite faire , c'est effectivement d'ajouter quelques modifications au code source d'origine , via la création de patches .asm indépendants . Autrement dit , je recherche quelqu'un qui pourrais écrire des fichiers ASM en s'aidant de documents déjà existants , et également d'un peu d'analyse de code . Es-ce illégale ?

  4. #4
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    septembre 2007
    Messages
    5 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 5 226
    Points : 13 084
    Points
    13 084

    Par défaut

    Si c'est sur SNES, ce n'est sûrement pas de l'assembleur x86. Impression renforcée par le fait que tu utilises des instructions telles que JSR, LDA, BEQ, BNE qui, elles, sont typiques des Motorola 68xx.

    Wikipédia nous dit qu'il s'agit d'un 65C816. Le 65C816 est une évolution 16 bits du 65C02, lui-même évolution technologique du 6502, lui-même successeur du 6501, lui-même développé par l'équipe à l'origine du 6800 et compatible broche à broche. On retrouve le 6502 dans pas mal de consoles essentiellement 8 bits, dans l'Oric Atmos, et d'autres.

    Pour le côté légal, le désassemblage est autorisé à des fins de reverse engineering pour interopérabilité, dans le cadre d'utilisation normal du produit, à condition que le fabricant ne publie pas déjà les informations nécessaires et de conserver confidentielles les informations ainsi acquises aux seules personnes qui ont participé à leur découverte.

    C'est effectivement un problème pour le patrimoine des 8 bits, par exemple. Ça fait un bon moment que l'on aimerait bien publier la table des registres internes (on ne parle même pas du code source à ce stade) de mon ancien TO8D. Le logiciel date de 1987 et pourtant, il ne s'agit même pas de la première génération (TO7/70, MO5) mais de la suivante. Malgré cela, il va rester la propriété intellectuelle de Microsoft pendant encore 45 ans, ce qui nous emmène en 2057.

  5. #5
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Pardonnez mon erreur d'inculte

    2057 , ça fait loin tout de meme ...

    Dans ce cas ,puis-je utiliser ce topic pour poser des questions sur le fonctionnement des commandes du 65C816 ? Car , il est vrais que j'avais commencé a apprendre ce language , mais dans la langue anglaise , alors il y a certains concepts que je n'ai pas réussi a saisir , une fois traduits (Comme par exemple , qu'est ce qu'une pille ? OU alors , pourquoi des fois certaines commande sont répétées plusieurs fois de suite ex: LSR,LSR,LSR,LSR ? Etc ...)

  6. #6
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    septembre 2007
    Messages
    5 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 5 226
    Points : 13 084
    Points
    13 084

    Par défaut

    Citation Envoyé par Vener Voir le message
    Pardonnez mon erreur d'inculte

    2057 , ça fait loin tout de meme ...
    Ouais, je trouve aussi. Et pourtant, certains ayant-droits (surtout dans la musique) trouvent que 70 ans, ce n'est pas encore assez long.

    Dans ce cas ,puis-je utiliser ce topic pour poser des questions sur le fonctionnement des commandes du 65C816 ? Car , il est vrais que j'avais commencé a apprendre ce language , mais dans la langue anglaise , alors il y a certains concepts que je n'ai pas réussi a saisir , une fois traduits (Comme par exemple , qu'est ce qu'une pille ? OU alors , pourquoi des fois certaines commande sont répétées plusieurs fois de suite ex: LSR,LSR,LSR,LSR ? Etc ...)
    Tu peux jeter un œil aux cours et tutoriaux dont l'adresse est en tête de page. Mais pour tes deux questions en particulier :

    Une « pile » (stack en anglais) est une structure de donnée extrêmement courante en informatique : il s'agit comme son nom l'indique d'un empilement de données successive, dont la particularité est que la dernière donnée entrée est la première ressortie (comme dans une pile d'assiette : on n'ajoute ou ne retire des assiettes que depuis le sommet).

    Tous les micro-processeurs ou presque proposent un registre de pile (S ou U sur Motorola et similaires). Ce registre pointe de l'espace libre en mémoire et dès lors que tu empiles une valeur, ce registre est automatiquement décrémenté de la taille de la donnée à stocker, puis la donnée est enregistrée à l'endroit nouvellement pointé. À l'inverse, lorsque tu dépiles une valeur, celle-ci est d'abord chargée, puis le registre est incrémenté.

    Ce mécanisme est implémenté sur la plupart des micro-processeurs parce qu'ils en ont eux-mêmes besoin, ne serait-ce que pour gérer efficacement les appels aux sous-routines avec JSR ou BSR, et dont il faut bien sauvegarder les adresses de retour successives. Les langages de plus haut niveau comme le C utilisent également la pile pour y placer les variables locales.


    Pour les LSR successifs, deux possibilités : soit il ne s'agit pas de code mais de données et ton désassembleur n'a pas fait la différence, soit c'est une technique qui se faisait beaucoup à cette époque : lorsque tu veux faire un scrolling en faisant défiler horizontalement les pixels d'une ligne, ou bien lorsque tu as des décalages de bits à faire sur de longs formats numériques (par exemple des double ou des long double), il est beaucoup plus intéressant de répéter plusieurs fois la même instruction plutôt que faire une boucle : d'abord parce que celle-ci t'oblige à initialiser un registre et donc à le sauvegarder si nécessaire, à l'utiliser et à faire des sauts conditionnels. Ensuite, parce que les LSR successifs sont beaucoup plus rapides !

    En effet, à chaque tour de boucle, tu vas comptabiliser les cycles de l'instruction LSR proprement dite ainsi que la décrémentation du registre et le saut conditionnel tant qu'on est pas à zéro. À elles-deux, ces dernières instructions sont plus longues en elles-mêmes que le décalage LSR. Donc, si tu ne manques pas de place, il est intéressant de multiplier les instructions, jusqu'à 100 itérations, à la louche.

  7. #7
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Merci beaucoup pour ces réponses détaillées !

  8. #8
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Bonjour , bonsoir .

    Après quelques réflexions (Et notamment un souci de restriction permanent), je pense qu'il serais plus intéressant de créer un jeu de A à Z , du moins essayer !
    Quelque chose sans aucun rapport avec 'Metroid' ; mais toujours dans un thème 2D & rétro (Une sorte de Zelda 3/Secret of Mana).

    Mais encore une fois , pas mal de questions arrivent : Cela vaut-il le coup en ASM ? Si oui , sous quel forme ASM (Si je veux que le jeu sois destiné à un usage sur PC Windows7) ? Quel serait la limite en taille ?

    Il y a aussi l'utilisation de la RAM ; par exemple , pour le 65C816 sur la plateforme Snes , la RAM peut lire simultanément 50 instructions/routines pour chaque types d'éléments , pas une de plus (50 ennemies , 50 portes , 50 PLM , etc ... ) . C'est déjà pas mal , mais pour un travail assez grand et vraiment détaillé , c'est insuffisant . Surtout que si le codage n'est pas très optimisé , un peu fouillis (car manquant d'expérience), le jeu risque rapidement d'avoir de la latence , avec trop de parcours des données .
    Enfin , il me semble .. je ne suis pas programmeur .

    Donc je me demandais quel serais le nombre de données pouvant etre exécutées simultanément pour un jeu ASM au format PC .

    Je ne prétend pas vouloir faire quelque chose tout seul , je connais des gens qui pourrais travailler avec moi , pour l'instant je me contente juste d'essayer d'établir un schéma des besoins (Exemple : Combien d'octets chaque ennemies devront contenir : un pointeur pour le son , les sprites & AI , palettes , collision , indices pour l'ordre de lecture etc , combien de graphic sets) , comportant combien de tuiles chaque uns , tout les objets , les textes pour chaque objets collectés , des indices pour chaque textes , etc ... 15 000 000 de petits détails quoi .

    Je vous remercies d'avance pour vos éventuels conseils !

  9. #9
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Chercheur d'emploi
    Inscrit en
    septembre 2007
    Messages
    5 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur d'emploi
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 5 226
    Points : 13 084
    Points
    13 084

    Par défaut

    Citation Envoyé par Vener Voir le message
    Mais encore une fois , pas mal de questions arrivent : Cela vaut-il le coup en ASM ? Si oui , sous quel forme ASM (Si je veux que le jeu sois destiné à un usage sur PC Windows7) ? Quel serait la limite en taille ?
    L'assembleur, c'est génial ! Mais si c'est pour travailler sur un PC contemporain sous un Windows de dernière génération, alors la réponse est clairement « non » : ce n'est absolument pas fait pour.

    Tu ne pourras pas travailler directement au niveau de la machine comme on le faisait avec les consoles et les 8-bits. Tu seras obligé de composer avec le système d'exploitation pratiquement tout le temps, d'abord parce que tu ne sauras jamais sur quel matériel exactement ton programme va fonctionner, ensuite parce que le système d'exploitation ne te laissera pas faire car tu fonctionneras en mode protégé. Tu vas donc être sans arrêt obligé d'appeler des macros INVOKE pour reconstruire les appels « à la C » et aller explorer à la main les structures de données renvoyées selon le même format. Tu ne disposeras pas non plus d'équipement dédié pour la gestion des sprites ou autre et tu ne pourras ni lire directement la VBL (dépendante de la carte graphique) ni faire des synchronisations en te basant sur le nombre de cycles puisqu'il faudrait tenir compte des systèmes de pipe-line et que, de toutes façons, les différents PC utilisent tous une cadence de processeur différente, sans compter les temps de latence liées au bus, à la mémoire et au reste du matériel.

    Ça resterait techniquement possible à condition d'initialiser, au départ, un environnement proche de celui des consoles de l'époque pour l'exploiter ensuite à l'intérieur de ton programme. Mais ce serait vraiment pour le plaisir de coder en assembleur et pas par stratégie technologique.

    Par contre, au point de vue mémoire, tu peux considérer que c'est illimité. Ma machine fonctionne avec 4 Go de mémoire et c'est pourtant considéré comme moyen aujourd'hui. À titre indicatif, sur mon TO8D, le BASIC et tout le système d'exploitation qui allait derrière (gestion des disquettes, de la cassette, du crayon optique, du clavier, du système de fichiers, des modes vidéos, de la rédaction du texte, etc. tout, quoi) tenait tout compris en 48 Ko ! Oui, « kilo ».

    Ma machine actuelle est donc dotée d'environ 87000 fois plus de mémoire vive ! Sans compter le swap. Tu n'auras pas assez d'une vie pour la remplir… du moins avec du code ! Avec de grosses images et de la musique numérisée, c'est une autre histoire, bien sûr.

    Il y a aussi l'utilisation de la RAM ; par exemple , pour le 65C816 sur la plateforme Snes , la RAM peut lire simultanément 50 instructions/routines pour chaque types d'éléments , pas une de plus (50 ennemies , 50 portes , 50 PLM , etc ... ) . C'est déjà pas mal , mais pour un travail assez grand et vraiment détaillé , c'est insuffisant
    Je ne suis pas au courant de ces choses-là. Peux-tu citer tes sources ? Ça m'intéresse.

    Le micro-processeur ou mêmes les circuits annexes n'ont pas conscience du fait que telle ou telle ressource est en soi un ennemi, une porte ou autre. Mais il arrive quand même qu'une circuiterie vidéo spécialisée soit capable de gérer elle-même un certain nombre de sprites. Mais certainement pas 50.

    Sinon, il n'y a pas de secret : si tu ne disposes pas de ces ressources, alors il faut se mettre à la place des personnes qui ont conçu ce circuit et re-concevoir un système similaire. Après, effectivement, ça finit par ramer quand il faut gérer trop de choses à la fois, mais c'est à toi de considérer ta machine comme un ensemble de ressource d'une puissance donnée, et de l'exploiter au mieux pour faire le maximum avec. Tout le challenge consistant, surtout à l'époque glorieuse de l'assembleur et des demomakers, à repousser ces limites et à écrire des choses que l'on considérait infaisables avec une machine donnée.

    Donc je me demandais quel serais le nombre de données pouvant etre exécutées simultanément pour un jeu ASM au format PC .
    « Simultanément », aucune. Pas plus qu'à l'époque d'ailleurs. Ce n'est vraiment simultané qu'à partir du moment où tu utilises des processeurs multi-core. À l'époque, on avait, comme dit plus haut, des circuits spécialisés pour les sprites ou autres. Rien de tout cela sur PC : tout se faisait avec la puissance brute du micro-processeur, qui est réellement très rapide lui aussi. Il est aujourd'hui de 500 à 3000 fois plus rapide que celui des consoles. C'est comme comparer la vitesse d'un astéroïde avec celle d'une personne qui marche à pied.

    Malgré ça, le besoin en puissance s'est quand même fait à nouveau sentir dans le courant des années 1990, ce qui a provoqué l'émergence des cartes graphiques pour le grand public. Ces cartes graphiques, par contre, ne proposent pas de systèmes dédiés de gestion des sprites ou autres mais un certain nombre d'unités de calculs à haute vitesse, très adaptés à la 3D.

    Je ne prétend pas vouloir faire quelque chose tout seul , je connais des gens qui pourrais travailler avec moi , pour l'instant je me contente juste d'essayer d'établir un schéma des besoins (Exemple : Combien d'octets chaque ennemies devront contenir : un pointeur pour le son , les sprites & AI , palettes , collision , indices pour l'ordre de lecture etc , combien de graphic sets) , comportant combien de tuiles chaque uns , tout les objets , les textes pour chaque objets collectés , des indices pour chaque textes , etc ... 15 000 000 de petits détails quoi .
    Aujourd'hui, il y a des bibliothèques qui font cela et qui permettent à tout un chacun de produire n'importe quelle application 2D en très peu de temps. Les grand débutants font cela en une semaine de travail, les codeurs aguerris y parviennent en deux heures. Et qu'importe si l'application est insipide et occupe des méga-octets pour rien.

    C'est pas vraiment la mentalité de l'époque, ni la mienne, mais c'est le moyen le plus facile de parvenir à un résultat fixé avec une machine donnée.

  10. #10
    Invité de passage
    Homme Profil pro
    Designer
    Inscrit en
    juin 2012
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Designer
    Secteur : Arts - Culture

    Informations forums :
    Inscription : juin 2012
    Messages : 6
    Points : 0
    Points
    0

    Par défaut

    Citation:
    Il y a aussi l'utilisation de la RAM ; par exemple , pour le 65C816 sur la plateforme Snes , la RAM peut lire simultanément 50 instructions/routines pour chaque types d'éléments , pas une de plus (50 ennemies , 50 portes , 50 PLM , etc ... ) . C'est déjà pas mal , mais pour un travail assez grand et vraiment détaillé , c'est insuffisant
    Je ne suis pas au courant de ces choses-là. Peux-tu citer tes sources ? Ça m'intéresse.
    Je ne sais pas si c'est spécifique au code source de Metroid ou pas , mais dans Metroid , dans la RAM il y a des adresses dédiées aux tableaux d'indices pour chaque éléments . A chaque fois qu'on ajoute un ennemie , une porte , une PLM , une pièce elle meme , un screen/scroll , etc .. on leurs donne un indice propre pour que le jeu puisse les différencier et les exécuter dans l'ordre , et le maximum est 50 (Ce sont des programmeurs désassemblant le jeu qui me l'ont dit , et puis j'ai eu l'occasion de tester tout ça) .Il est vrais que cela ne s'applique pas pour la totalité des éléments utilisés par le jeu. Après , pour la VRAM , certains graphismes sont compressés (Par exemple , pour les ennemies apparaissant à l'écran , le maximum de bytes pouvant etre lues pour les sprites est $1600) , les tuiles pour le level data (layer 1,2,& 3) sont compressées encore différemment et le nombre utilisable semble etre illimitée , d'après ce que j'ai pu tester . C'est assez complexe etant donnée que chaque secteur a plus ou moins son propre mode de fonctionnement .

    D'ailleurs , en gros , comment crée-on une "RAM map" ? Faire que chaque adresses de la RAM effectue tel ou tel choses , puisqu'en désassemblant , on ne peut pas 'ouvrir' une adresse RAM pour voir ce qu'elle contient .

    Ça resterait techniquement possible à condition d'initialiser, au départ, un environnement proche de celui des consoles de l'époque pour l'exploiter ensuite à l'intérieur de ton programme. Mais ce serait vraiment pour le plaisir de coder en assembleur et pas par stratégie technologique.
    Je parle d'ASM parce que c'est le seul langage que je comprend un peu .
    Mais bon , parait-il que Java est plus simple , alors pourquoi pas apprendre le Java , ou meme un autre , tant qu'il est possible de retranscrire ce qu'on imagine à la perfection .

    Aujourd'hui, il y a des bibliothèques qui font cela et qui permettent à tout un chacun de produire n'importe quelle application 2D en très peu de temps. Les grand débutants font cela en une semaine de travail, les codeurs aguerris y parviennent en deux heures. Et qu'importe si l'application est insipide et occupe des méga-octets pour rien.

    C'est pas vraiment la mentalité de l'époque, ni la mienne, mais c'est le moyen le plus facile de parvenir à un résultat fixé avec une machine donnée.
    J'ai vue ça , c'est vrais que c'est un gain de temps ENORME , mais je pense que c'est tout de meme plus adapté de concevoir "tout" de A à Z . Je pense que si on est fort en conception/architecture pour les objets , les batiments , etc (mon métier) ... on peut l'etre aussi pour le codage , et surtout si on est quelqu'un d' hyper prévoyant (voir parano lol).

    c'est à toi de considérer ta machine comme un ensemble de ressource d'une puissance donnée, et de l'exploiter au mieux pour faire le maximum avec. Tout le challenge consistant, surtout à l'époque glorieuse de l'assembleur et des demomakers, à repousser ces limites et à écrire des choses que l'on considérait infaisables avec une machine donnée.
    Je suis parfaitement d'accord avec cette idéologie ! D'ailleurs , depuis 2-3 ans que j'étais sur Metroid , en apprenant et tenant compte de toute les variables , j'ai vue qu'il était possible d'optimiser l'espace en conséquence , et d'ajouter un très grand nombre d'éléments , pour en faire un jeu 2X plus grand et complexe . Mais comme je disais précédemment , quand on se rend compte qu'on a des idées qui affluent en permanence , qu'on aime les micro détails partout et qu'on est capable de tenir compte de beaucoup de variables pour concevoir quelque chose sans oublier de failles , le mieux serais de faire son propre truc .

    Sinon , en parlant de "demomakers" , je ne sais pas si Nasir Gebelli en est un ou non , mais pour des personnes comme ça , qui sont capables de coder un jeu a elles seules , peut-on dire que ce sont des génies , ou es-ce que tout le monde peut y arriver avec BEAUCOUP de temps et de travail ?

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •