[Recrutement] Projet : Last dungeon

[Neckara]

Merci beaucoup pour votre intervention.

Par contre est-ce que je peux utiliser openSSL avec des sockets boost (le système de callback est très intéressant pour relier un socket à un client).

Par contre je remarque une énorme faille dans votre schéma.
Pour le 3 ème message, le paquet sera toujours le même donc même sans connaitre le mot de passe (ou son hash), le login, ou les clés RSA, il suffit de "copier" le paquet et de l'envoyer au serveur, il faut donc rajouter lors du message 2 un sel à ajouter au message 3.

Sinon je suppose que openSSL peut créer des clés RSA à volonté donc qu'on peut, pour le client, générer une clé RSA à chaque connexion afin d'éviter de la stocker en dur côté client?

Derrière il faut bien évidement vérifier la cohérence du contenu du paquet.
Il n'y aurait alors plus que 2 failles "corrigeable" :
- la connexion SSH : interdire la connexion par mot de passe et utiliser une clé.
- les ports ouverts.

Par contre, si je ne dis pas de bêtises, les connexions acceptées utilisent un port unique différent de celui du socket d'écoute ?
Il faut donc fermer tous les ports à l'exception du port SSH, du port d'écoute et garder une plage de port ouvert pour les connexions (?).

Après avec cela, je ne sais pas si on peut faire plus à mon niveau.

[Emmanuel Deloget]

Envoyé par Neckara

Merci beaucoup pour votre intervention.

Par contre est-ce que je peux utiliser openSSL avec des sockets boost (le système de callback est très intéressant pour relier un socket à un client).

Pas de soucis majeurs. OpenSSL est une librairie de fonctions bas niveau. Ecrire l'adapteur pour boost est tout à fait possible.

Il me semblait même que Asio (la lib socket intégrée à Boost) proposait le support de HTTPS via, probablement, OpenSSL. Mais je peux me tromper.

Envoyé par Neckara

Par contre je remarque une énorme faille dans votre schéma.
Pour le 3 ème message, le paquet sera toujours le même donc même sans connaitre le mot de passe (ou son hash), le login, ou les clés RSA, il suffit de "copier" le paquet et de l'envoyer au serveur, il faut donc rajouter lors du message 2 un sel à ajouter au message 3.

Ce n'est qu'un schéma

En ce qui concerne la faille, je suis à la fois d'accord et pas d'accord, parce que...

Envoyé par Neckara

Sinon je suppose que openSSL peut créer des clés RSA à volonté donc qu'on peut, pour le client, générer une clé RSA à chaque connexion afin d'éviter de la stocker en dur côté client?

C'est le cas

Du coup, le message de login n'a pas nécessairement besoin d'un salt - si à chaque connexion, on crée un couple clef publique/clef privée. Ce qui est plutôt une bonne chose en fait, parce que si le même client reste avec la même clef de connexion pendant trop longtemps, on ne peut plus (à l'heure actuelle) assurer qu'elle restera inviolée face à un décryptage en bruteforce (grâce à la Rapsberry Pi, les supercalculateurs sont maintenant à un prix abordable - pour 10000€, on peut se faire un calculateur composé de plus de 250 machines - ça commence à être du costaud...).

Envoyé par Neckara

Derrière il faut bien évidement vérifier la cohérence du contenu du paquet.
Il n'y aurait alors plus que 2 failles "corrigeable" :
- la connexion SSH : interdire la connexion par mot de passe et utiliser une clé.

C'est effectivement une solution : un certificat, coté client, généré par le serveur et envoyé à la première connexion ou récupéré sur le net à l'inscription.

Envoyé par Neckara

- les ports ouverts.

Par contre, si je ne dis pas de bêtises, les connexions acceptées utilisent un port unique différent de celui du socket d'écoute ?
Il faut donc fermer tous les ports à l'exception du port SSH, du port d'écoute et garder une plage de port ouvert pour les connexions (?).

Après avec cela, je ne sais pas si on peut faire plus à mon niveau.

Le protocole SSH n'est pas nécessairement le protocole à utiliser. Il ne permet pas le changement de clef en temps réel sur les clients connectés (quelque chose qui peut être utile sur un MMO).

[Neckara]

Bonjour,
Étudiant de 19 ans en deuxième année de D.U.T informatique, j'ai commencé en même temps que mes études un projet qui me tient à cœur : Last Dungeon.

Présentation du projet :

Last Dungeon est un projet en deux parties.
La première est similaire à un jeu de Go (jeu chinois millénaire).
Le jeu de Go se joue en posant des pions sur un plateau, le but étant de « manger » les pions adverses en les entourant sans laisser d'espaces libres et en ayant un maximum d'espaces libres entre ses propres pions.
Nous proposons quelques innovations comme le fait de pouvoir jouer sur plusieurs plateaux à la fois et de pouvoir jouer en équipe contre plusieurs adversaires.

Un mode scénario vous apprendra à jouer et servira de prélude à la deuxième partie.

La seconde partie est un RPG multijoueur à monde persistant s'inspirant des jeux Zelda et reprenant la première partie comme énigmes dans les donjons et comme mode JcJ (joueurs contre joueurs).
Nous nous pencherons vraiment sur cette dernière partie qu'une fois la première terminée.

Le jeu est développé en C++ avec les bibliothèques boost, irrlicht 3D et SFML.
Nous espérons avoir une version jouable mais non-présentable début janvier 2013.


Membres du projet :

- Léo Jean : étudiant en 2ième année d'ingénieur en informatique nous a rejoint dans cette aventure dès ses débuts et même si du fait de ses études il est peu disponible, il reste d'un très grand soutient. Il s'occupe principalement des sons. Vous pouvez d'ailleurs écouter quelques-unes de ses créations sur notre chaîne youtube.
- Sentinelle : infographiste 3D très prometteur qui a déjà produit quelques images très sympathiques.
- Djeck det : programmeur C++ (avec Irrlicht)
- Guillaume : programmeur C++ qui gère aussi notre site.
- Neckara : programmeur C++ qui s'occupe aussi de la gestion de l'équipe, du projet ainsi que du site.


Projet :


Langages : C++
Bibliothèques principales : Irrlicht 3D/boost/SFML
Graphismes : graphismes 3D.
Type de jeux : Jeux de réflexion.
Mode de jeux : en ligne et hors-ligne
Résumé du scénario de la première partie :
Vous vous réveillez sans savoir qui et où vous êtes. Deux créatures similaires à des poulpes (Polype et Poliapa) vous guideront à travers des épreuves de Go. Ils vous récompenseront d'un bout d'histoire sur un certain capitaine Gnasse à la fin des épreuves...
Résumé du scénario de la seconde partie :
Un navire s'échoue sur un continent inconnu après une tempête. Malheureusement ces terres ne sont pas aussi hospitalières qu'elles n'y paraissent. Vous devrez alors récupérer d'anciens artefacts dans des donjons pour survivre et progresser à l'intérieur des terres.


État du Projet :

Après un an de développement nous avons décidé de repartir sur des bases saines et de tout recommencer à 0.
Actuellement nous avons fini toute la partie analyse et conception et nous entamons le développement.

Nous prévoyons avoir une version jouable d'ici janvier 2013.
Nous ferons aussi d'ici quelques temps une vidéo de l'état du projet actuel.


Nous recherchons :

Pour le moment notre équipe est complète.

Bien sûr, toute personne intéressée et voulant aider peut nous contacter.


Pour plus d'informations :

Pour plus d'information, vous pouvez consulter notre site ( http://jsz.kegtux.org/ ) ou nous contacter.

Vous pouvez aussi consulter notre galerie et notre chaîne youtube (n'hésitez pas à vous abonner).
Les vidéos datent un peu mais une nouvelle est prévue d'ici quelques temps.


Nous contacter :
- via MP : neckara
- via notre site (partie contactez-nous) : http://jsz.kegtux.org/drupal/formulaire
- via ce sujet.

[Dabou Master]

Oula le projet est méconnaissable ! oO

Ou alors je n'avais rien compris en premier lieu ^^.
Il me semblait aussi qu'à la base ça devait être de la 2D, m'enfin j'ai lu tellement de présentations de projet depuis que j'avoue que je n'en m'en souviens plus très bien.
Ce que je n'ai pas compris c'est le côté première/deuxième partie, comment apparaissent-elles ? Au début j'avais cru comprendre que le jeu de Go remplaçait les phases de combat, en poursuivant ma lecture je me rends compte qu'en fait il y a un scénario différent pour chacun des aspects du jeu. J'aimerais juste connaître le lien entre ces deux parties (siouplait).

Le côté graphique a été mis plus en avant à ce que vois, même si là il est difficile de savoir ce qu'est supposé représenter chaque image même si je crois reconnaître un des poulpes ^^. Les modélisations mécaniques sont vraiment jolies mais pour celles organiques il va falloir se faire violence pour rendre le tout plus convaincant ^^. D'ailleurs j'ai une question vis à vis des graphismes, tout ce que je vois a l'air d'être assez fortement polygonisé (oui dit comme ça ça ne veut rien dire mais c'est compréhensible non ?) alors est-ce que ce qui nous est montré là est supposé tourner en temps réel dans le jeu ? Ou est-ce que ce n'est que le menu qui est en pré-calculé ou alors même le jeu sera constitué de scènes pré-calculées ?

Depuis le temps que je suis ce projet je vais peut être enfin comprendre de quoi il s'agit .

[Neckara]

Envoyé par Dabou Master

Oula le projet est méconnaissable ! oO

Ou alors je n'avais rien compris en premier lieu ^^.
Il me semblait aussi qu'à la base ça devait être de la 2D, m'enfin j'ai lu tellement de présentations de projet depuis que j'avoue que je n'en m'en souviens plus très bien

Il est vrai que le projet a pas mal changé depuis sa création. Nous avons commencé un peu trop inexpérimenté sans réellement savoir où nous nous dirigions. Il nous a fallu un peu de temps pour acquérir une équipe stable et avoir une vision claire de ce que nous allons faire et comment.

Envoyé par Dabou Master

Ce que je n'ai pas compris c'est le côté première/deuxième partie, comment apparaissent-elles ? Au début j'avais cru comprendre que le jeu de Go remplaçait les phases de combat, en poursuivant ma lecture je me rends compte qu'en fait il y a un scénario différent pour chacun des aspects du jeu. J'aimerais juste connaître le lien entre ces deux parties (siouplait).

Demandé comme cela je ne peux pas refuser.
On peut distinguer 4 composantes principales dans l'utilisation de la première partie :
- Le JcJ donc l'affrontement entre joueurs.
- Le mode scénario qui servira de prélude à la seconde partie.
- Les énigmes similaire au mode scénario mais utilisé dans les donjons de la seconde partie.
- La partie édition pour créer ses propres plateau, énigmes etc...

La seconde partie sera "à la Zelda", le "Go" ne remplacera pas les phases de combats mais sera utilisé comme énigmes/épreuves dans les donjons.
Exemple : aller rechercher des pions dans des salles pour les poser sur un plateau de "Go" et déverrouiller une porte.
La seconde partie étant déjà assez ambitieuse, nous avons voulu créer une première partie à notre projet pour poser certaines bases et s'habituer à nos outils tout en aillant quelque chose de jouable relativement rapidement.

Envoyé par Dabou Master

Le côté graphique a été mis plus en avant à ce que vois, même si là il est difficile de savoir ce qu'est supposé représenter chaque image même si je crois reconnaître un des poulpes ^^. Les modélisations mécaniques sont vraiment jolies mais pour celles organiques il va falloir se faire violence pour rendre le tout plus convaincant ^^.

Disons que maintenant qu'on a un vrai côté graphique, on en profite un peu.
Pour les modélisations organiques je les trouves plutôt bien mais je pense qu'en tant qu'infographiste 3D tu dois avoir une meilleure perception que moi. Après, ce ne sont pas des poulpes mais des entités similaires à des poulpes (cela nous permet de justifier toutes nos erreurs de graphismes ).
Ensuite je trouve que notre infographiste est assez doué : il me semble que c'était la première fois qu'il réalisait des modélisations organiques et il ne lui a même pas fallu une semaine pour arriver à des résultats assez satisfaisants ( ce n'est que mon point de vue en tant que non infographiste).

Envoyé par Dabou Master

D'ailleurs j'ai une question vis à vis des graphismes, tout ce que je vois a l'air d'être assez fortement polygonisé (oui dit comme ça ça ne veut rien dire mais c'est compréhensible non ?) alors est-ce que ce qui nous est montré là est supposé tourner en temps réel dans le jeu ? Ou est-ce que ce n'est que le menu qui est en pré-calculé ou alors même le jeu sera constitué de scènes pré-calculées ?

Je n'ai pas la moindre idée du taux de polygonisation ( ça ne veut rien dire non plus ^^ ).
La majorité des animations (pions/socles/décors) seront precalculées et seront placée dans une scene 3D.
Quant aux poulpes je pense que cela dépendra des animations.

Si tu as d'autres questions, n'hésite surtout pas

[hatra]

Bonjour,

Dans un premier temps ... sache que je te trouve tres courageux de prendre les devant tout en etant en plein e formation ...(sache que tout de meme faire un UML meme si c'est enneuyeux ... mais en clair le travail à effectuer et met de la disipline...) .

Etant etudiant en jeux video .. j'ai ete curieux par ton projet ... et j'ai juste une question ... pourquoi n'avoir pas choisie un moteur comme Unity(le plus puissant le, le plus facil à utilisé ... ne dispose d'aucune limite pour moi ...) ou le celebre UDK? paourquoi faire du sdl?? (surtout que la sdl etait prevue pour le c auqui ne sipose pas d'objet ... meme si les structures ...)

[Neckara]

@Dabou : Pour répondre à ta question :
1700 points pour les pions et 9 000 pour le socle.
On a des images aussi jolies car il utilise le subsurf.
Pour les essais il a désactivé le subsurf et le rendu n'est pas génial, il faut que j'en parle avec lui.


@hatra : Le C n'est pas un langage orienté objet mais on peut faire de la programmation orienté objet avec.
J'ai fait éditer récemment le premier post de ce sujet pour mettre à jour les informations (très vieillottes). Le jeu est programmé en C++ avec Irrlicht.

[Dabou Master]

Salut,

Par points tu entends vertices ? (J'avoue qu'on je n'avais jamais entendu parler de points, à la rigueur de polygones, de faces). Ensuite comme le subsurf (catmull - clark j'imagine) ça rajoute des polygones intermédiaires pour rendre tout plus lisse et courbe, il faut prendre en compte le nombre de polygones une fois le rendu effectué (je sais que dans Blender c'est affiché en haut à gauche du rendu) et c'est là qu'on se rend compte du vrai compte. Sachant qu'en plus tout passe au final en triangles (et que le subsurf nécessite des polys à quatre côtés, appelés quads souvent) on se retrouve en plus souvent avec le double de polygones que ce qu'on pensait. C'est d'ailleurs comme ça que j'ai foiré la première modélisation sérieuse de ma vie qui s'avérait être un low-poly ^^.

Enfin pour résumer, un low-poly, en considérant que vous voulez faire tourner votre scène en temps réel, ne doit jamais comporter des modifiers qui vont altérer le compte de polygones (polycount). C'est normal que le rendu soit horrible sans subsurf vu la qualité présente des courbes des rendus, l'idéal serait une retopologie après avoir fait un baking des normals pour donner un aspect plus lisse, mais sous certains angles on pourra voir la supercherie, mais tout le monde fait comme ça. Ou alors vous faites de la tesselation et là moi je vous applaudis des mains et même des pieds !

Sinon il vous reste les scènes pré-calculées et donc logiquement non interactive, et là vous pouvez laisser les modifiers de style subsurf sans souci (c'est même fortement conseillé de ne pas les appliquer s'il y a de l'animation, mais dans tous les cas on évite de les appliquer).

En espérant avoir apporté des informations qui pourraient être utiles à ton graphiste, et en espérant avoir une réponse que je comprenne la prochaine fois ^^.

[Neckara]

Bonjour,

Après une petite semaine de programmation il est désormais possible de poser et enlever des pions.

https://www.youtube.com/watch?v=wiU3...ure=plpp_video

Nous avons malheureusement de petites difficultés avec les graphismes mais nous travaillons dessus.

Je pense aussi que nous allons suivre une méthode proche de l'agile c'est à dire que nous allons chaque semaine ajouter une fonctionnalité parmi les plus importantes et chaque samedi je générerai la documentation et ferait parfois une petite vidéo.

Concernant notre communication, je pense mettre une petite news chaque semaine sur notre site.
Pour la newsletter ou les posts sur developpez, je ne sais pas si je vais garder la même fréquence, à voir.

[MoDDiB]

Pourquoi Irrlicht et pas Ogre3D ?

Personnellement j'avais préféré Ogre, mais bon c'était il y a 7 ans

[Neckara]

Envoyé par MoDDiB

Pourquoi Irrlicht et pas Ogre3D ?

Personnellement j'avais préféré Ogre, mais bon c'était il y a 7 ans

Pourquoi pas Irrlicht?


Tout d'abord, d'après ce qui est dit un peu partout, Irrlicht et Ogre3D sont un peu équivalent à la différence que Irrlicht serait plus simple d'utilisation et Ogre3D plus complet.
Après, c'est une de nos recrues qui nous avait conseillé et il ne voyait pas vraiment en quoi Ogre3D était plus complet d'Irrlicht.

Pour faire le meilleur choix possible, il aurait fallu tester les deux mais c'est comme pour le langage de script qu'on va utiliser (Lua interfacé avec Lunar), il aurait fallu qu'on teste une bonne 12ène de scripts, or tester ne veut pas dire juste faire un code avec mais l'utiliser pour voir ses limites, ses avantages etc... donc ça prend pas mal de temps.

Après, tant qu'Irrlicht permet de faire ce que nous souhaitons...
Si jamais on doit changer pour une raison X ou Y, il faudra juste réécrire quelques parties des classes "Vue" mais ceci ne devrait pas arriver

[MoDDiB]

Si je posais la question c'est parce que je n'ai jamais entendu parler de Irrlicht dans le milieu professionnel et je souhaitais comprendre le pourquoi, la facilité d'accès me semble un bon point. ( mais Ogre n'est pas si méchant )

Sinon le plus simple et le plus rapide pour se faire une idée d'une techno c'est de comparer les réalisations avec les technos respectives.

[Neckara]

Bonjour,

Je me suis pris une petite semaine de repos donc je n'ai pas vraiment avancé.
Les plateaux et les cartes sont chargées à partir de fichiers, donc dès qu'on aura fini l'éditeur, vous pourrez créer vos propres cartes (il est possible des les faire à la main mais c'est assez fastidieux). Les règles sont enfin implémentée sous forme de script Lua, c'est à dire que n'importe qui peut créer ses propres règles.

Comme vous pouvez le constater, le problème du FPS a été résolu.
Notre infographiste a refait des éléments plus légers ce qui nous a permis de passer de 5FPS à 17FPS et j'ai modifier le code pour passer de 17 à 24 FPS.
Sachant que non seulement mon ordinateur n'a pasde carte graphique mais une chipset graphique et que cette chipset n'est pas utilisée au maximum de ses performances, 24FPS est vraiment le minimum que vous pourrez avoir, avec un bon ordinateur vous devriez avoir un FPS 10 à 100 fois plus élevé.

Concernant les sources, comme je ne les ai pas encore bien commenté, je ne les publierais pas cette semaine.

Règles - YouTube

Règles - YouTube

[Neckara]

Bonjour,

Voici une nouvelle vidéo :

Client IRC - YouTube

Client IRC - YouTube

Par contre le son est vraiment trop faible... mettez le son à fond et utilisez un casque et vous entendrez (peut être) quelque chose

Il faudrait que je me trouve une bonne âme qui puisse amplifier le son pour la vidéo ...

[Neckara]

Bonjour,

Cela fait un petit bout de temps que nous n'avons pas donné de nouvelles.

Neckara est désormais en stage mais il est malheureusement très dépendant des ses moyens de transports. Il a donc un peu de temps libre mais il ne peut pas vraiment travailler sur le projet. Il en profite alors pour traduire les tutoriels d'Irrlicht ce qui lui permet aussi d'approfondir ses connaissances sur le moteur graphique que nous utilisons.

Pendant les week-end, il avance un peu le code. Pour le moment, il travaille avec un membre de developpez.com : Lininux pour réaliser un serveur. Nous avons presque fini la base du serveur, il ne nous restera ensuite qu'à créer la "base du client" et enfin d'ajouter les différents traitements.

Comme nous avons déjà un mode offline fonctionnel, il nous manque surtout la gestion des utilisateurs et des salons ainsi qu'une réécriture rapide du mode offline. Cela ne devrait pas être vraiment très long à faire mais il nous manque un peu de temps.

Au niveau du graphisme, malheureusement, notre infographiste n'est plus trop disponible. Heureusement, notre secrétaire a un nouvel ordinateur et pourra de nouveau nous aider, nous pensons alors renforcer notre communication interne et ainsi motiver chaque membres au maximum pour tenter d'en faire un petit peu plus chaque jours.

Nous hébergeons maintenant notre propre serveur mumble auquel ont accès les membres de l'équipe et certains membres de developpez. Si vous voulez y avoir accès et/ou avoir un petit channel pour votre propre projet, n'hésitez pas à me contacter

Cordialement,

L'équipe Last Dungeon

[Kannagi]

C'est normal que tu te parle a la troisième personne ?(ou t'es devenu schizophrène ).

[Neckara]

Envoyé par Kannagi

C'est normal que tu te parle a la troisième personne ?(ou t'es devenu schizophrène ).

Je n'ai pas écrit cette newsletter mais c'est l'équipe de Last Dungeon qui l'a écrite (bon en fait ça revient au même ), d'où l'utilisation de la 3ème personne.

[Linunix]

Bonjour Neckara,

J'ai aperçu une de tes discussions dans la rubrique réseau...
Et j'ai vu que tu allais faire un serveur SMTP , pourrais-tu mettre des news à ce sujet sur ton projet ^^

Allez Neck, bonne journée

[Neckara]

Bonjour,

Je te remercie pour l'intérêt que tu porte à notre projet.

En fait ce n'est pas réellement un "serveur SMTP", juste une application qui enverra des mails en dialoguant avec des serveurs MX.

Je réalise cette application dans le cadre de mon stage mais je pense la réutiliser pour Last Dungeon pour les inscriptions :

L'utilisateur renseigne son E-mail, je lui envoit un mail avec un code de confirmation à l'intérieur et ce dernier devra renseigner ce code pour valider l'inscription auprès du serveur soit pendant l'inscription soit à la première tentative de connexion.

[Linunix]

Oui, bonne idée.

Je pense qu'il serait meilleur de faire confirmer lors de la 1 ere connexion.