Jeuxlinux - Le site des jeux pour linux - Forum

energy a écrit:

Enfin quelqu'un qui propose quelque chose de concret
j'aimerais juste faire 2-3 remarques ( oui je sais je suis chiant )

mais non, ça va, les remarques sont bien expliquées donc constructives

energy a écrit:

les modèles de personnages présents dans open arena ne correspondent pas du tout a l'image que l'on se fait d'un survival horror ou d'un western , meme futuriste ( un peu style lanfeust , ou plutot un "space" cow boy avec des armes style bioschok ? ( des vieilleries completement améliorées ) . Il faudrait donc pourvoir faire de nouveaux modeles , ou en "emprunter" a un jeu libre ( tout en sachant que les modeles de smoking'guns sont forts grossiers...

Tu ne m'as pas compris, le fait d'utiliser les données d'Open Arena permet de s'occuper en premier lieu du code et du fonctionnement, l'aspect viendra après, il sera bien plus facile de motiver un graphiste si le jeu est déjà prêt. L'idée est de ne pas de voir attendre d'avoir fait les modèles 3D pour commencer à coder.

energy a écrit:

Ensuite, il existe quantités de moteurs, pour quelles raisons celui d'open arena serait il le meilleur ? plus léger ? plus facile a utiliser/ modifier?  N'est-ce pas déja un moteur trop compliqué pour des débutants tels que nous? Ou au contraire ne peut on pas directement choisir un moteur de rendu plus performant? tel que X-real? ( je demande simplement, j'y connais rien )

L'intérêt du moteur d'Open Arena est qu'en se basant sur Open Arena on lui emprunte plus que son moteur, on reprend carrément tout le code et du coup il y a certaines choses que l'on aura pas besoin de recoder, comme le suport réseau ou les bots (on les modifiera mais on aura une base)
Je ne connais pas bien les autres moteurs, je sais juste que faire un mod pour Open Arena facilite beaucoup la tache et permet de démarrer en douceur.

energy a écrit:

Mais au niveau rendu final, il faudrait pouvoir modifier un peu le moteur pour qu'il y ait plus de contraste, beaucoup de sombre et un peu de clair qui tranche fort, et bannir les couleurs trop vives, le jeu devrait avoir des dominantes noires et rouges ( et oui le sang ca tache )
A moins que nous ne partions sur un autre style de survival...

Pourquoi pas, si on part sur un jeu standalone, on pourra éventuellement retravailler le rendu, on en discutera je ne suis pas sûr que ça soit un priorité.

energy a écrit:

Et pour terminer, existe t'il des outils libres qui nous permettraient de nous simplifier la tache ? pour mapper plus facilement par exemple .

aucune idée, si quelqu'un sait, ça m'intéresse.

energy a écrit:

et enfin, ( oui idée nouvelle , ne frappez pas ) pourquoi ne ferait on pas un concept a la FPS creator? ou en tout cas une base de jeu faite exprès pour que d'autres recondent dessus ?

Ça ça me parait bien trop compliqué, ça s'éloigne énormément de l'idée de base et ça ne répond pas vraiment à un besoin, je ne suis pas sûr que les joueurs ait envie d'un jeu comme ça. (bref, pour moi c'est non, ça diverge trop du projet)

Bon je rajoute une couche

Pourquoi utiliser OA eh bien comme déjà dit, ça permet entre autres de coder tout en utilisant les données d'OA, c'est-à-dire qu'on va commencer à modifier le comportement des armes, les mouvements des personnages, etc … Le tout sans aucune donnée, enfin sans nouvelles, que celles d'OA. Ensuite dès que la base est posée il sera plus facile de se trouver un graphiste, voire plusieurs. Parce que sur le genre de jeu, je crois que l'ambiance sera assez importante.

Ensuite le moteur d'OA (ioquake3 donc) est multiplateforme (Linux, Win32, MacOS, Solaris pour les versions officielles) mais c'est aussi un moteur souple et stable.

Pour ce qui est du moteur d'Xreal c'est en fait ce même moteur, mais modifié, donc je pense pas que ce soit plus difficile de l'utilise, le seul bémol serait peut-être la non garantie d'avoir un support efficace des développeurs et une version stable et éprouvée. En sa faveur jouent ses ajouts (http://xreal.sourceforge.net/xrealwiki/Features) et ses graphismes plus alléchant

Pour la base du projet énoncé je suis prêt, de toute façon j'ai prévu ce genre de mod OA pour commencer.

Pour les maps sur ce moteur faut se débrouiller avec GTKRadiant à moins qu'il existe autre chose que je connais pas.

je veux bien m'occuper de la partie sonore et des graphismes 2d ( menus ...  )

si on se cantonne a poster l'annonce ici ca va pas bouger beaucoup, il faut un site web et de la pub

Pas sans moi !

Je m'occuperai du code, et avec Julroy67 de préférence, sachant qu'on a moyen de bosser en binome. Vraiment très content de l'initiative !

Mcmic, je te plussoie, tu propose enfin quelque chose de concret et plausible, tout en proposant d'utiliser le moteur ioquake3.

Enfin tu parles d'un mod OpenArena, pour ma part je pense que c'est mieux de faire un jeu à part entière, quitte à forker, parce qu'on ne suivra pas le développement d'OpenArena mais du moteur ioquake3 qu'il utilise.

Enfin pour le moment ce ne sont que des points de détails.

Tu propose un FPS coopératif ?
Je suis à 100% d'accord et je te propose mes services, mon générateur de niveaux pour Quake 3 (écrit en Python) et mes maigres connaissances en C (je cherche justement un projet pour apprendre).
Ainsi que mes bonnes connaissances du fonctionnement du moteur Quake 3 (pas mal de modding/mapping sur hl1 et 2).

Et mapping avec GtkRadiant sur quelques dérivés de Quake3.

Dernier détail, quake3 n'est pas écrit en C++, mais en C, faudra que tu t'y fasses.
Cela dit, je pense que tu es chef de projet, à toi de guider le troupeaux

Par contre comme souvent, je pense que l'on risque de manquer de graphistes, non ?

Désolé si je suis en désaccord, mais je connais bien le moteur de Quake 3, je peux en une heure te monter un moteur de base avec une carte (minimale) et quelques textures.

On peut récupérer des donnes depuis OpenArena, mais en faire un mod (c'est à dire dépendre des 400 Mo d'OA) est contre productif, alors que je peux te monter le strict minimum dans 20 Mo.

D'autant plus qu'OA n'a rien à voir puisqu'on utilisera bien le moteur ioquake3, c'est juste un projet de graphistes, ils créent du contenu libre autour du moteur Quake 3 ou plutôt son fork ioquake3.
Je ne bosse pas sur OA, mais je crois bien qu'ils n'ont pas édité une seule ligne de code, si ce n'est pour modifier le répertoire de base des données ou des détails genre les menus.

Tout ce qui est ajouté à la jouabilité d'OA vient de ioquake3.

Je sais pas si c'est clairement expliqué, mais je pense que l'on devrait plutot penser ioquake3 qu'OA

Pour te prouver tout cela, je peux te faire dès ce week-end un mini jeu avec une carte de test et quelques textures qui servira de base, tu n'aura qu'a récupérer de ton côté le code d'ioquake3 et voir rapidement comment ça fonctionne.

Comme tu l'as dit, le plus dur sera de programmer les bots, dans ce sens, je pense que je devrais créer des cartes de tests, mais pour ça il faudra que tu me dises de quel manière.
Si tu ne sais pas, je devrais pouvoir me débrouiller, mais dans l'immédiat, je risque de pas coder, je suis encore en phase d'apprentissage et je suis sur djl 1.2.0 en ce moment. (quand il sera terminé, je serais déjà plus disponible).

Par contre, je sais pas si tu sera d'accord, mais je compte bien mettre en pratique les générateur de niveaux que j'avais programmé l'an dernier.
Il est pas fini, c'est l'occasion de s'y mettre.
En réalité je parle ici d'une idée un peu ambitieuse, on ne créé pas de cartes pour le jeu (sauf peut être pour le multi), elle pourraient être générés par le jeu, juste avant une partie.

En désactivant quelques optimisations ou encore RAD, je peux générer un labyrinthes d'environ 1000 blocs en une minute.

Diablo150 a écrit:

Par contre, je sais pas si tu sera d'accord, mais je compte bien mettre en pratique les générateur de niveaux que j'avais programmé l'an dernier.
Il est pas fini, c'est l'occasion de s'y mettre.
En réalité je parle ici d'une idée un peu ambitieuse, on ne créé pas de cartes pour le jeu (sauf peut être pour le multi), elle pourraient être générés par le jeu, juste avant une partie.

En désactivant quelques optimisations ou encore RAD, je peux générer un labyrinthes d'environ 1000 blocs en une minute.

Je suis pas sûr que ce soit une bonne idée, pour la simple raison que les joueurs aiment connaitre les cartes et qu'ils ont leurs préférences.
Sur tous les jeux auxquels j'ai joués, il y avait toujours des maps "jouées" et des maps que les joueurs n'aimaient pas.
Par exemple sur Killing Floor (un mod très proches de ce qu'on veut faire), les maps manor, grudge ou d'autres sont très appréciées, et pourtant le but est juste de résister à des vagues de zombies.

Sans parler, que si le "scénario" du jeu évolue un peu, les joueurs devront avoir des points de repère.
Exemples: magasin sur killing floor, banque sur smokin'guns, site bomb sur cs, ...
Par contre un générateur de niveaux, fera gagner un temps précieux aux mappeurs.

D'ailleurs en parlant de scénario il serait temps de si intéresser, et de commencer à en écrire un. Même si ce n'est pas obligatoire pour que l'on commence à dev, mais au moins pour avoir une ligne de conduite, et que l'on ne commence pas à développer des trucs qui au final ne serait pas utilisé.

En ce qui concerne un site pour le projet, voulez-vous que j'installe un site de suivi de projet (comme pour djl) ou un wiki ? Je peux également installer un serveur svn, ben oui si on code à plusieurs il va falloir des sources centralisées

Moi je voterais bien pour un wiki du moins, c'est plus simple pour gérer entre nous et le svn bah on peut passer par une forge (Google Code, SourceForge, ou autre équivalent libre) plutôt non ? (éviter de prendre de l'espace disque).

Pour ce qui est de OA/ioquake3 je partais sur l'idée que pour faire rapidement du code on allais utiliser les models/maps/etc de OA simplement pour éviter de se retrouver à chercher ces données. Mais on peut démarrer sur un truc neuf si on a le minimum, ce qui est tout à fait faisable.

Je pense que si il faut quand même écrire un mini scénar', du moins quelque chose qui va définir le sens qu'on va prendre. Le mieux étant (je pense) de se fixer des objectifs pour éviter de se disperser sur des choses inutiles. Bon sûr que on va pas avoir un truc complet pour faire un mod solo qui d'ailleurs n'est pas le but à ce que je sache ? ^^

Ensuite euh pour le moment on a donc assez de codeurs je pense pour démarrer un POC.

Je vois aussi que vous partez sur l'idée des bots, mais moi je voyais ça plus sans bots. C'est-à-dire qu'on a 1 joueur au hasard qui sera le 1er zombie et c'est à lui de contaminer les autres, ce qui va réduire petit à petit les survivants. Et donc il faut plus jouer en équipe pour survivre. Bon après sans bots, c'est qu'il faut des joueurs là aussi ça peut poser problème j'en conviens, mais perso c'est toujours plus amusants avec des joueurs qui jouent souvent mieux que les bots tout de même. Je peux aussi partir sur d'autres idées à tester, on peut soit donner des armes pour se défendre, soit favoriser la fuite. On peut jouer sur beaucoup de paramètres.

Enfin ce genre de truc est à définir en priorité, qu'est-ce qu'on fait exactement comme jeu ?

Et bon chef de projet MCMic c'est toi si tu le veux, je suis pas un leader ^^

MCMic a écrit:

un POC?

Proof of concept

MCMic a écrit:

comment ça un scénario oO c'est juste un bande de branlos contre des vagues de zombies, ya pas des masse d'histoire (enfin on verra pour un mod histoire après)

Ben même pour un mod de ce style il faut bien un scénario (ou un cahier des charges) qui définisse exactement le concept du jeu.
Qu'elles sont les classes des zombies ennemis ?
Qu'elles sont les classes jouées par les joueurs ? leurs avantages/inconvénients ?
Les armes utilisées ?
Le but du jeu ? est ce seulement tuer tous les zombies, ou réaliser un objectif ?
Pour y arriver, quels sont les moyens ? seulement des armes pour tuer les zombis ou aussi du "matériel" ?
(par exemple dans killing floor, on peut se soigner ou soigner ses coéquipiers. On peut avoir un fer à souder, pour bloquer certains passages et forcer les zombies à rentrer que par un point d'accès) Ça donne un coté un peu plus stratégique, que simplement une boucherie de zombis...

Il faudrait également définir une charte graphique, pour que des contributeurs graphistes puissent nous créer des objets, textures, ...
Peut être même avoir des concepts art pour avoir une idée proche du rendu du jeu final !

Je vais installer un wiki ce week-end, comme ça on pourra tous participer à la rédaction de ce "cahier des charges".

julroy67 a écrit:

Je vois aussi que vous partez sur l'idée des bots, mais moi je voyais ça plus sans bots. C'est-à-dire qu'on a 1 joueur au hasard qui sera le 1er zombie et c'est à lui de contaminer les autres, ce qui va réduire petit à petit les survivants. Et donc il faut plus jouer en équipe pour survivre. Bon après sans bots, c'est qu'il faut des joueurs là aussi ça peut poser problème j'en conviens, mais perso c'est toujours plus amusants avec des joueurs qui jouent souvent mieux que les bots tout de même. Je peux aussi partir sur d'autres idées à tester, on peut soit donner des armes pour se défendre, soit favoriser la fuite. On peut jouer sur beaucoup de paramètres.

Les fps sont quasiment tous players vs players, et les fps coopératif sont très rares, ce qui est bien dommage.
Je trouve qu'il est bien plus intéressant de se retrouver peu nombreux et de devoir lutter tous ensemble pour un objectif commun, plutôt que d'être joueurs vs joueurs et que les parties tournent au ffa.
Sans parler qu'avec un fps coopératif tel que nous l'envisageons, le jour où tu es tout seul pour jouer, ben tu peux jouer quand même

Avec un fps classique, les forces doivent êtres équilibrées, 6 contre 6 ou 10 contre 10. Avec un fps coopératif, le rapport de force peut être disproportionné :  1vs30 à 6 vs 120 pour killing floor, 1 vs 350 pour serious sam
Et ça a un coté tellement plus jouissif ^^

Si en plus de ça on arrive à donner un petit coté stratégique pour renforcer le jeu d'équipe la sensation de jeu sera alors quelque chose de nouveau par rapport à tous les fps classiques que l'on connait.

personellement, je pense que
1- il faut un mini scénario ( on aime toujours savoir pourquoi on tape, ca motive ) genre contamination massive et on est les seuls survivants ou quoi, une connerie mais qui met l'ambiance.

2-il vaut mieux etre par exemple  6 joueurs vs 300 bots , pour deux raisons : on n'aura pas assez de joueurs et on ne fera peut etre pas une IA assez intelligente pour avoir un nombre faible de mechants ( peut etre style left 4 death, les bons sont des humains , les mauvais de base des bots et les mauvais "améliorés" des joueurs , ca permettrait d'avoir un jeu a 300 personnages en étant que 10 )

3- l'ambiance graphique doit dépendre du mini scénario, on ne se voit pas peter du zombie en environnement graphique clair et chatoyant ou casser de l'indien dans une athmosphere sombre a la doom....

4- en ce qui concerne le générateur de maps , on peut l'utiliser et puis  peaufiner les maps ainsi créées, ca permettrait surement d'accélerer la création .

5- il vaut mieux faire ca en premiere personne, on a un champ de vision plus réduit, plus "direct", ca donne plus de sensations et de challenge ....

Je suis globalement d'accord avec les idées proposées. Je retiens :
- Un jeu en coopération joueurs vs bots, avec un avantage numérique clair pour les zombies.
- Au niveau du gameplay, 2 types à retenir : la fuite et la défense. Dans le cas de la fuite, les zombies devraient revenir en nombre illimté, et dans le 2eme cas, les humains devraient tenir à un nombre donné de vagues.
- Les zombies doivent être un peu plus rapides que les humains pour rendre le jeu nerveux. Ca a l'air de n'être qu'un détail, mais pourtant c'est très important.

Par contre, au niveau de l'interaction avec le décor, on risque d'être limité par le moteur physique. Killing Floor est basé sur UT2K4, qui propose un bon moteur physique,lui.
Il faut donc s'attendre à devoir mettre en place un certain nombre de scripts si on ne veut pas rendre le gameplay trop inintéressant.

L'arrivée prochaine de Left 4 Dead (Valve) est de bon augure, car il pourrait nous apporter un bon nombre d'idées originales.

Bref, j'attendrai la mise en place du wiki pour reparler de tout ça.