Salut à tous, je viens vous présenter mon modeste petit projet
Présentation du projet
Scalable Zombies est un simple petit jeu de tir à la première personne développé en C avec la librairie SDL.

- Pourquoi «Scalable» ?

A l'origine j'avais pensé développer le jeu à base d'images vectorielles (SVG, ou "Scalable Vector Graphics"), cependant je me suis vite rendu compte que c'était une solution peu pratique à mettre en œuvre avec la librairie SDL, j'ai donc renoncé au SVG, mais pas au nom !

- Pourquoi développer un jeu de zombies ?

Je sais que c'est un sujet déjà abordé des centaines, voire des milliers de fois, mais ce petit projet n'est fait que pour mon apprentissage de la SDL, et j'aime bien les Zombies.

Synopsis
Toute votre vie, vous avez vécu calmement dans un building tranquille d'une quelconque métropole. Aujourd'hui, c'est fini, les zombies attaquent et vous devez survivre ! Utilisez toute votre habilité pour arracher la tête de ces non-morts avant qu'ils ne vous arrachent la vôtre !

Les zombies sont lents, stupides, mais nombreux, ne vous laissez pas encercler !

Visez la tête pour anéantir les quelques étincelles de vie qu'il leur reste.

Cadre spatio-temporel
Scalable Zombies prend place dans une grande ville moderne couverte de buildings et d'autres marques de civilisation.
Quant à l'époque on se retrouve au 21e siècle, sans beaucoup de précision par rapport à la date.

Fonctionnement du jeu
Chaque niveau commencera par quelques images qui serviront de cinématiques, vous ne contrôlerez pas les déplacements, uniquement la visée.

L'objectif de chaque écran sera de détruire toutes les vagues de zombies pour passer à l'écran d'après.

Seules quelques touches seront normalement utilisées : il sera possible de mettre le jeu en pause avec le bouton P, ou de revenir au menu avec la touche Esc.

Les sauvegardes se feront automatiquement après chaque niveau, impossible de sauvegarder en cours de vagues.

La musique pourra être désactivée avec la touche M (ou S si les différents types de claviers posent problème, je ne sais pas si la SDL est sujette à ce genre de soucis).
Le clic gauche tirera et le clic droit servira à recharger.

Cartes
Étant donné que vous ne pourrez pas influencer les déplacements, il n'y aura pas de cartes, un seul itinéraire sera possible.

Cinématiques
Les cinématiques seront simplement des suites d'images avec des dialogues.

Graphismes
J'aimerais des graphismes du style "nouveau vieux RPG", des zombies avec un bord noir qui glissent sur un décor fixé dans le fond.

Pour une meilleure idée des graphismes, j'aimerais qu'ils ressemblent à ceux de cette image :
(Capture d'écran tirée du jeu Era of The Beast, http://www.digital-coproductions.com/games/era-of-the-beast/wiki )

http://www.digital-coproductions.com/media/files/wikifile/file_document/1300543393interface_05_2010.jpg

Son
La musique sera beaucoup dans les basses, très dynamique excepté dans certaines cinématiques ou menus.

Le réalisme n'est pas de mise.

Humour
Le jeu se veut volontairement très cliché est avec un humour de très mauvais goût, de l'humour noir aux jeux de mots vaseux.

---------

Ceci dit, je profite de ce topic pour appeler à l'aide. Je sais qu'il me reste des choses à écrire et à penser, mais cette base m'était suffisante pour coder, je suis cependant devant un mur.
Je suis capable de programmer le jeu, je peux même me débrouiller pour faire de la mauvaise musique, mais je suis incapable d'obtenir des graphismes qui ressemblent à quelque chose.
Je recherche donc un graphiste qui serait intéressé par ce projet, et qui voudrait m'aider en me proposant quelques décors de fonds et quelques sprites qui respecteraient le pseudo-aspect graphique décrit dans le cahier des charges plus haut.
J'ai par contre le regret de ne pas pouvoir proposer de rémunération, il s'agit uniquement de proposer un jeu gratuit, sympathique et libre.

Si un musicien est intéressé par ce jeu je suis également preneur !

Je suis contactable par MP, ou par e-mail à l'adresse roman@yling.be

--------

Je suis à l'écoute de toutes vos critiques par rapport aux idées notées plus haut, et je le serai encore plus par rapport à mon code, que je posterai dès que j'aurais réussi à dessiner un premier niveau ou si je trouve un aimable dessinateur.

--------

J'aimerais que tout le contenu du jeu soit libre, bien que je ne proposerai évidemment pas des images libres si un dessinateur me contacte et qu'il ne souhaite pas qu'on puisse réutiliser les dessins.

Salut à tous, YliNG. (Alias Meat ou Roman )

Voilà, en attendant de posséder des graphismes, je vais déjà poster mon main.c, qui sert uniquement à afficher le menu principal, qui se compose de quatre boutons :
- Jouer
- Instructions
- Quitter
- A propos

Seuls les boutons quitter et à propos sont implémentés pour l'instant.

http://pastebin.com/RceE7zFR

J'ai conscience que c'est peu de chose, mais quelques conseils d'optimisation ou des modifications à faire m'aideront déjà à améliorer mon code dans le futur

Merci d'avance !

tout ce code dans le main.c!

ou as-tu donc appris à faire un code pareil, aka tout mettre dans le main?

En faisant du PHP

En fait ça me semblait logique que le main.c contienne le menu qui va appeler les autres fonctions (la fonction permettant de jouer par exemple) contenues dans les autres .c, mais apparemment ça se fait pas \o/

MER IL EST FOU!

Un petit refactoring s'impose ? Voudrais-tu que je retrouve un bon template pour réagencer son code assez facilement que j'avais expliqué quelque part un jour dans un autre temps sur un autre forum. C'est assez concis mais vu que tu as l'air de comprendre ce que tu as écrit cela ne devrait pas te prendre beaucoup plus que deux trois heures de travail.

non mais habituellement, main.c contient pas beaucoup de trucs, c'est plus du genre:

int main()
{
application game=new application();

return application.run();
}

application.run contiendrait une fonction de gestion des interaction, la boucle de jeu, etc, le tout dans des fonctions séparées et avec des objets séparés, c'est plus organisé. tout mettre dans le main donne un code brouillon, illisible et pas maintenable.

Tbop2 C'est exactement le genre de genre de trucs que j'attendais en postant ici \o/

caelacanthe Je vois, ben je vais organiser ça proprement avec le template de Tbop alors

Ah oui mais attends mon template c'est dans la même lignée que pense caelacanthe : c'est un truc qui s'apparente pas mal a de la POO donc le transposer a du C ça va pas être simple pour toi. Tu n'as aucune notion de POO/C++ ?

POO si, C++ aucune

Ok. Bon désolé mais ma solution s'applique globalement à de la POO.

https://www.jeuxvideo.com/forums/1-31-8600925-1-0-1-0-sfml-probleme-modification-de-tableau.htm#message_8600939

C'est très concis j'espère que tu comprendras. Le gros truc qui va te poser des problèmes dans ton code c'est de bien séparer tes fonctions update et draw de tes énormes et monstrueux switch événementiels de ta version actuelle.

pour que ce super projet ne coule pas

enfin, il ne va pas couler si le topic n'est pas uppé toutes les 24 heures...

Meat tu n'as pas fini si tu post ton code source. a mon sens c'est une très très mauvaise idée. Tu vas prendre un temps énorme a changer ton code en suivant leurs conseils (qui peuvent etre bon là n'est pas la question) au lieu de le faire par toi meme. De tout facon entre mainteant et le final ton arhitecture changera bien 4 5 6 10 fois, donc c'est totalement initule de poster ton code.

ca ne sert a rien de commencer par menu, a propos etc... Commence direct pas le jeux en lui meme.

Et surtout ne post pas le code source avant un jeux bien avancé !!! Ou post des bout d'algo ou demande des noms de méthodes pour ca ou ca, mais jamais ton code en entier c'est un conseil si un jour tu veux finir un jeux.

Mouais. Refactorer un code de 225 lignes c'est pas la mort à boire. Autant le faire maintenant parce que sinon... Oh mon dieu.

Moui, mieux vaut faire l'autruche et ne sortir le code source que quand il sera devenu vraiment inmaintenable que trier les conseils et apprendre à prioriser les tâches d'un projet.
C'était le conseil du mois.

Tiens mec il est temps que tu bouffes ça, il y a des trucs pas parfaits mais c'est quand même très sympa, fancy et en français (mes respects à l'auteur s'il passe par ici d'ailleurs).

http://poj.b3dgs.com/page.php?lang=fr&section=engine

Pour que son code soit inmatenable il faudrai déja qu il avance dessus. Pour qu il avance dessus il faut qu il se l'approprie et surtout que le choix de refaire tel ou tel bout de code vienne de lui et pas d'un autre. Donc quand il sera rendu a un code inmatenable il aura déja fait un grand pas ! Un premier grand pas obligatoire je dirai meme.

Si c'est pour faire comme les autre disent et pas comme lui pense autant ne pas le faire. Et qui prouve que ta facon de faire sera mieux que la sienne ?

Donc j en revien a mon conseil principal, ne post pas l ensemble de tes source ou les casse bonbons te ferrons toujours des remarques sur plein de morceau de code et tu n'avancera jamais !! Lis des codes sources des tuto ou autre et inspire toi de ca plutot que de conseil de mec qui n ont sans doute jamais avancé un projet et qui vienne de donner de "précieux conseils"

Aproprie toi ton code et ta facon de faire. Es confiance en toi.
Tu as vue bcp de projet fini ici qui ont demandé conseil au autre en refilant tout les code source? Non. parce que si toutes les 500 ligne tu le fait tu ne finira jamais.

1. Kaoron Voir le profil de Kaoron
2. Posté le 20 août 2011 à 16:02:25 Avertir un administrateur
3. Moui, mieux vaut faire l'autruche et ne sortir le code source que quand il sera devenu vraiment inmaintenable que trier les conseils et apprendre à prioriser les tâches d'un projet.

C'était le conseil du mois.

j'ai pas compris pourquoi on est arrivé jusque-là alors qu'il n'a posté qu'une seule fois son code source.

En soi si on exclut la partie totalement incompréhensible de :

"Lis des codes sources des tuto ou autre et inspire toi de ca plutot que de conseil de mec qui n ont sans doute jamais avancé un projet et qui vienne de donner de "précieux conseils""

Donc si j'écarte cette partie hautement optionnelle j'en arrive à dire que c'est bien beau acemicka je n'ai pas grand chose à contredire, tu prêches la paix, l'harmonie... Mais concrètement qu'est-ce que cela à voir avec le topic et toutes les réactions (plus qu'amicales) de tous les forumeurs jusqu'à présent ?

"Et qui prouve que ta facon de faire sera mieux que la sienne ?"
1) Caractéristiquement à première vue, le créateur du forum n'aime pas la compilation séparée, les fonctions en C... Ce qui fait normalement partie de la base du langage. On parle pas là de mettre trois indentations au lieu d'une, d'écrire son code et ses commentaires in English, ou que la notation hongroise c'est la vie. On parle d'utilisation optimale des fontions de base offertes par le langage C.
2) Concernant le template que je lui donne il est plus que répandu. Si tu développes en XNA tu le verras, si tu développes en Android tu le verras, si tu développes sur un projet de jeu un minimum sérieux tu le verras. J'ai plus les livres en tête mais c'est une très bonne distinction logique et pragmatique d'un code source pour un jeu vidéo (cf. le magnifique petit tuto que j'ai retrouvé).

Pour le reste, hormis les casse-bonbons, je suis grossièrement d'accord avec toi... mais encore une fois en prêchant la paix on s'attire pas tant d'ennemis que ça.

de facon tangentielle, pour causer de temps en temps avec Meat hors-bande (sur irc), je pense qu'il est grand et qu'il saura trier les conseils cons des conseils utiles. Si il obtient des conseils utiles (a ses yeux), il les suivra, sinon il ne les suivra pas.

Poster un code complet et demander un avis global, c'est pas la meme chose que de demander une review ligne par ligne. (Et de toute facon, il n'obtiendra pas de review ligne par ligne, parceque globalement, les forumeurs n'ont pas que ca a foutre.)