lundi 08 septembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de Slainer :

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

Posté par Slainer (Jabber id, page perso, ) le 21 août 2005
0
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.

> Lire le journal (16 commentaires, moyenne: 4,4).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

sdl

Posté par martoni (page perso, ) le 21/08/2005 à 21:15. (lien). É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(...)

--
Un jour les manchots seront les maîtres d'un monde sans pétrole gnark gnark gnark !!

  • [^]Re: sdl

    Posté par Keph (page perso, ) le 21/08/2005 à 21:25. (lien). É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 tuiu pol (Jabber id, ) le 22/08/2005 à 12:00. (lien). É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 Farvardin (page perso, ) le 21/08/2005 à 21:26. (lien). É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.

--
You can't grep dead trees...

Allegro

Posté par ahuillet (page perso, ) le 21/08/2005 à 21:30. (lien). É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 :)

  • [^]Re: Allegro

    Posté par martoni (page perso, ) le 21/08/2005 à 21:36. (lien). Évalué à 3.

    c'est vrais qu'elle a l'air assé intéressante aussi Allegro !

    --
    Un jour les manchots seront les maîtres d'un monde sans pétrole gnark gnark gnark !!

  • [^]Re: Allegro

    Posté par Nicolas ANTONIAZZI (page perso, ) le 21/08/2005 à 22:47. (lien). Évalué à 4.

    SDL Une usine à Gaz par rapport à allegro ?

    Moi je dirais plutôt l'inverse!

    Le nombre de fonctions proposés par SDL est réduit au minimum des fonctions qui permettent d'accéder aux matériels tout en étant indépendant de la plateforme. http://www.libsdl.org/intro.fr/tocfr.html(...)

    Allegro permet aussi de le faire mais propose des tas de fonctions pour gérer les GUI, les sons, de gérer les effets graphique et plein d'autre choses... http://www.allegro.cc/manual/index.php(...)

    Ensuite, chacun choisit ce qu'il préfère. Il existe donc des extension spécifique pour SDL qui améliore des morceaux (sge pour les effets graphique, sdl_mixer pour le son, etc...) mais aussi pour allegro (http://www.allegro.cc/resource/index.php?id=1)(...)

    Donc, au final les 2 libs sont aussi fournis l'une que l'autre... mais en partant sur l'API de base, SDL n'a rien d'une usine à gaz comparé aux autres libs.

nekeme

Posté par baud123 (Jabber id, page perso, ) le 21/08/2005 à 21:47. (lien). É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 EdB (page perso, ) le 22/08/2005 à 07:25. (lien). Évalué à 3.

    et #nekeme sur irc.freenode.org

langages de scripts et exécutables "stand alone"

Posté par Krunch (Jabber id, page perso, ) le 21/08/2005 à 23:37. (lien). É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.

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Python, pygame, soya

Posté par Guillaume Bouchard (page perso, ) le 22/08/2005 à 00:39. (lien). É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 Rémi Hérilier (page perso, ) le 23/08/2005 à 00:06. (lien). É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 Slainer (Jabber id, page perso, ) le 22/08/2005 à 06:22. (lien). É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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0969s (dont 0.0176 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !