Journal Que pensez-vous du SDK de développement de jeu Torque 2D/3D ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
21
août
2005
Bonjour à tous et toutes !

Je suis étudiant dans l'informatique et je souhaiterai m'initier à la création de jeux vidéo. La belle histoire me direz vous ! Non mais je reste modeste, j'aimerai créer des tous petits jeux, juste en 2D, style jeux de plateforme, de plateaux, etc... pour m'initier.

En fait, ce que je recherche, c'est un truc pas trop compliqué mais en même temps complet qui me permette aussi directement et relativement facilement de jouer des sons, etc...

J'ai regardé un peu toutes les solutions, mêmes propriétaires. Les solutions comme Dark Basic semblent sympatiques, je l'avais même acheté à l'époque. Un langage BASIC simple mais qui permettait de faire des trucs sympas, et de concevoir un .exe au final. Malheureusement propriétaire et que sous Windows.

Je suis tombé récemment sur le site GarageGames.com qui propose lui aussi un SDK propriétaire "tout en un, clés en mains". Il s'agit de Torque 2D et Torque 3D. Pour résumer, il s'agit d'un moteur qui a été utilisé dans un ancien jeu de Sierra, et qui est maintenant en vente. Pour 100 dollars on peut avoir un accès privé aux sources du moteur, sans l'autorisation de diffuser les sources, juste les utiliser/regarder et les améliorer à titre personnel. Récemment ils ont sorti une version 2D de leur moteur (celle qui m'intéresse).

Le SDK est fourni avec des exemples de jeux déjà réalisés, des éditeurs (tiles, particules), le moteur son est intégré. Le SDK est utilisable directement en C++ ou via un langage de script dérivé du C++ (TorqueScript). Les programmes compilent avec GCC sous Windows, MacOS X et Linux.

Qu'en pensez-vous ? Pensez vous que c'est une bonne affaire pour 100$, ou avez vous d'autres solutions à me proposer (sachant que je voudrais des programmes finaux compilés, pas des scripts comme du Python, etc) ? Est-ce que je devrai plutot tout de suite me mettre à SDL ?

Merci pour vos commentaires.

  • # sdl

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    y a pas photo met toi directement a sdl, c'est vraiment simple à utiliser et c'est multiplateforme !

    j'avais fait le jeux de la vie avec sdl et j'avais vraiment trouvé ça simple !

    voir sur mon site:

    http://fabienmarteau.free.fr/rubrique.php3?id_rubrique=8(...)

    J'ai plus qu'une balle

    • [^] # Re: sdl

      Posté par  (site web personnel) . Évalué à 4.

      Je déconseille. D'un point de vue perfs c'est l'horreur (alpha blending en software).
      Par contre, je recommende chaudement Clanlib (clanlib.org). Bien pensé, bien faite, avec rendu OpenGL, c'est très bien.

      Bon je dis ça sans avoir lu le journal, je répond juste à ce commentaire qui conseille SDL. SDL c'est bien mais pas top :)

      • [^] # Re: sdl

        Posté par  (site web personnel) . Évalué à 9.

        D'un point de vue perfs c'est l'horreur (alpha blending en software).

        Alors d'une part, les alpha blitters en soft de SDL sont parmi les plus rapides qu'on peut trouver (écris en assembleur MMX).

        Et d'autre part, avec glSDL (SDL qui utilise OpenGL pour la 2D) on peut avoir l'alpha blending en hard :
        http://icps.u-strasbg.fr/~marchesin/sdl/SDL12-experimental.tgz(...)
        http://icps.u-strasbg.fr/~marchesin/sdl/glsdl.html(...)

        Espérons qu'on trouvera bientôt glSDL dans les release officielles de SDL...

      • [^] # Re: sdl

        Posté par  . Évalué à 4.

        Clanlib c'est bien .. quand on le connait, parceque pour "rentrer" dedans la doc est réduite au strict minimum et on se retrouve à partir à la pêche aux fonctionnalités. C'est galère pour débuter parceque ça demande un plus gros investissement qu'avec SDL par exemple.

  • # trop fermé

    Posté par  . Évalué à 5.

    je ne suis pas programmeur, le peu de photos que j'ai vu sur le site en question semblent annoncer un produit pas mal, seulement moi cela me semblerait trop restrictif comme licence. J'aurais l'impression que si je m'embarque là-dedans, je ne pourrait pas réutiliser les connaissances acquises du fait des licences :

    par ex :
    "When you release a T2D-based game, you have to be careful not to give away the T2D editors or your source scripts. People shouldn’t be able to use your game as a game-making tool! Part of the T2D EULA states that you must remove the T2D-specific editors (tile editor and particle editor, for now) from your project before you release, and that you must not release any un-compiled scripts containing T2D-specific code (though, you can release raw scripts which don’t contain T2D-based code)."

    SDL ou pygame me semblent bien mieux à ce point de vue là. Pourquoi pas du python ? ("Python c'est bon mangez-en" (tm) ). Sur le site de pygame il y a des exemples de jeux et c'est bien rapide et pas ridicule du tout.

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Allegro

    Posté par  (site web personnel) . Évalué à 5.

    C'est plus simple que SDL, et ça marche tout aussi bien.
    Bon évidemment c'est moins fourni, mais SDL est vraiment une usine à gaz.

    Pas le temps de détailler, essaie, tu te feras ton avis :)

  • # nekeme

    Posté par  (site web personnel) . Évalué à 5.

    demande aux gens de nekeme : http://nekeme.net(...)
    http://nekeme.net/fr/?name=Nekeme/Contacts(...)

    ils ont des jeux sympathiques et pourront t'orienter je pense...

    • [^] # Re: nekeme

      Posté par  . Évalué à 3.

      et #nekeme sur irc.freenode.org

  • # langages de scripts et exécutables "stand alone"

    Posté par  (site web personnel) . Évalué à 3.

    Tu peux parfaitement générer un exécutable "indépendant" avec un langage "de script". En tout cas avec Perl et Python c'est possible.

    http://par.perl.org/(...)
    http://python.org/doc/faq/windows.html#where-is-freeze-for-windows(...) (seulement pour Windows)

    Sinon 100$ pour un SDK de jeu 2D propriétaire dont tu ne pourra pas faire ce que tu veux alors qu'il y a des tonnes de jeux libres disponibles gratuitement ça me semble beaucoup mais bon.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Python, pygame, soya

    Posté par  (site web personnel) . Évalué à 8.

    Salutations,

    J'aimerais savoir ce que tu as contre Python par exemple. Personellement j'etais dans le meme besoin que toi, a savoir faire un jeu simple et modeste. J'ai longtemps cherche une bonne solution et c'est python qui s'est impose :

    - Language tres puissant, il est moins rapide que le C mais les lib que tu peux utiliser sont en C donc en fait tu obtiens quelque chose de tres correct sur le plan rapidite. Et tu peux utiliser pyrex qui te permet de generer des librairies en C a partir de code python, te faisant gagner un maximum de temps

    - Langage tres facile a prendre en main. La ou en C tu te battras avec des malloc, tu n'auras aucun de ces soucis en python

    - Enormement de libs/bindings

    opengl openal, sdl, tu as vraiment tout ce que tu veux

    - Des outils vraiment sympas comme pygame ou soya3d http://home.gna.org/oomadness/en/index.html(...)

    - Portable.


    Bref, pourquoi te casser la tete avec des libs payantes surement interessantes mais limitees et non libre alors que tu as du libre de tres bonne qualite a cote.

    PS : desole pour les accents, VN keyboard.

    • [^] # Re: Python, pygame, soya

      Posté par  . Évalué à 2.

      J'aimerai bien savoir ce que tu as contre le C. À chacun des programmes que je développe, je choisis le langage qui me parait le plus adapté car chercher le Langage (attention à la majuscule:) s'est avéré être une absurdité. Et oui, s'il existait, tout le monde n'utiliserait aucun autre langage. Mais revenons au C :

      - Langage très puissant. Il est rapide car il est bas niveau et on sait depuis longtemps l'optimiser.

      - Langage certes plus difficile à prendre en main mais connaître toutes les subtilités d'un langage prend du temps. La gestion de la mémoire est effectivement à la charge du développeur mais un code bien structuré élimine la majorité des risques. De plus, les risques de fuites de mémoire dépendent de la compléxité du programme. Si on ajoute à cela une documentation du code, ces risques s'amenuisent encore lorsque l'on reprend son code quelques semaines ou mois plus tard.

      - Énormement de bibiliothèques de fonctions.

      - Portable (mais bon, le code du programme l'est mais qu'en est-il des bibliothèques de fonctions ?)

      Bref, Le choix est large mais il ne dépend pas que des possibilités de tel ou tel langage/bibliothèque. En plus de ses besoins/contraintes, il dépend aussi de ses propres connaissances et de ses affinités. Mais là, on ne peut pas grand chose pour Nicolas ... Le plus simple est effectivement d'aller sur irc et de demander des avis puis de forger sa propre expérience.


      Perso, je reste fidèle au C++/SDL/OpenGL (je ne fais que de la 3D) pour 2 raisons essentielles :

      - imposer un minimum de contraintes à l'utilisateur de mon programme. Un linuxien n'a aucun problème pour rajouter un paquetage (qui est sûrement déjà installé car un autre programme en dépend déjà) alors que pour un windowsien ou un maceux, c'est moins sûr.

      - faire en sorte que mes programmes fonctionnent decemment sur les petites configurations.

      bon, j'vais arrêter là, il se fait tard ^_^

      PS: en plus de #nekeme, essaye #codefr =)

  • # je vais me mettre au python

    Posté par  (site web personnel) . Évalué à 5.

    bon bah finalement, suite à tous vos commentaires, je pense que je vais me mettre au langage Python :).
    De plus j'ai pu lire d'autres commentaires sur ce langage qui peut etre intéressant pour faire des scripts shell et des scripts IRC. Donc ça peut etre intéressant à plusieurs niveaux de l'apprendre, surtout que je me destine plus à devenir admin systeme que programmeur pur et dur.

    merci pour vos commentaires !

    Nicolas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.