SpaceBall - Page 1

Salut,

Je viens de terminer mon travail de fin d'études, il s'agit d'un casse briques réalisé en C++ avec la librairie SDL.
Je vous propose de le tester et de me dire ce que vous en pensez.
Bien sur ce n'est pas aussi abouti qu'un Arkanoïd, j'ai fait en fonction du temps que j'avais devant moi et de mes capacités...
Il y a seulement 5 stages, bien que cela ne prenne pas vraiment de temps d'en réaliser. 5 Stages sont amplement suffisants pour que le jury du travail puisse se faire une idée des possiblités du soft. Je ne pense pas qu'il auraient été jusqu'au bout du jeu s'il y en avait eu plus. Pour la même raison la difficulté du jeu n'est pas très élevée.
Trève de blabla voici le lien pour télécharger le jeu:

Lien

Je vous remecie d'avance pour vos commentaires.

Maxime

EDIT: les commandes:

Space Ball - Commandes

Menu:
F1: jouer
F2: afficher high scores
ESC/Fermer Fenêtre: quitter
TAB: switch fullscreen

High Scores:
ESC/Fermer Fenêtre: retour au menu
TAB: switch fullscreen

Partie:
Souris: déplacements
BT Gauche Souris: lancer bille
ESC: quitter partie
TAB: switch fullscreen
P: pause

Touche de triche:
F1: ajouter 1 bille (Bonus B)
F2: passer le stage (Bonus L)
F3: réduire palette (Bonus P-)
F4: agrandir palette (Bonus P+)
F5: ajouter 500 points (Bonus S)

C'est marrant .. mais c'est un peu lent (augmenter la cadence n ferait pas de mal)
et il y a des bug de collisions avec la raquette (barre)

Ha zut, il me semblait que les bugs de collision de la raquette étaient règlés
Tu peux m'en dire plus sur ce qui se passe concrètement?
Pour la vitesse as-tu essayé de passer en fullscreen? C'est légèrement plus rapide.
Sinon si ça reste trop lent tu dois avoir un PC un peu ancien (testé sur un Duron 750 c'est très lent) . Comme je ne suis pas un super programmeur mon jeu est hélas gourmand.
Une des raisons est que la balle avance pixel par pixel, un choix que j'ai fait pour simplifier mes collisions.
MErci pour ton post en tous cas

Pour la vitese il se peu aussi que même si le jeu tourne normalement tu le trouve un peu lent il n'est pas aussi rapide que certains autres. Mais je ne voulais pas qu'il soit réservé au Hardcore gamers

pour les bugs, ils suffit d'essayer d'attraper la balle au dernier moment avec la raquette... cela en genere plusieure

Je pense que je vois ce que tu veux dire. Tu vois la balle superposée à la palette et tu perds tu vie quand-même?
Si c'est ça c'est parceque la balle a déjà atteind la limite du bas de l'écran et donc on perd sa vie.

non il y a d'autre chose comme la balle se fige sur la palette ou la balle rebondis rapidement dessus (genre elle vibre)

ou que la balle rebondis sur le milieu (donc à l'interieur) de la palette

-

-> Xirius: ha zut alors, c'est plus embêtant que je ne le pensais
-> Orion: c'est un graduat d'informatique, mais en cours du soir. Du coup ça reste assez léger. C'est malheureusement orienté geston donc base de données et cie. Ca ne m'a pas plus du tout en fait. Niveau programation par exemple, en tout j'ai eu seulement 3 cours de 120h: delphi, c et c++. Pour les deux derniers on a employé Borland C++ version DOS, pas génial quoi.

Je viens d'apporter une correction qui devrait avoir résolu le problème de collision avec la raquette.
Je suis en train d'uploader la nouvelle version.
Xirius peux-tu me dire si ça va mieux?
Merci

Désolé de te demander de faire ce test mais je dois le rendre demain, j'aimerais qu'il soit le mieux possible

-

Oui j'ai pu le reproduire. En principe c'est corrigé. Lors d'une collision avec la raquette je remet la position_balle.y au niveau de départ, ainsi elle n'est jamais plus d'un tour de boucle en contact avec la raquette. Visuellement c'est plus agréable aussi
Si tu as l'occasion de tester la nouvelle version (uploadé au même endroit) c'est cool

Tu pourrais aussi par exemple ajouter dans ton test "position_balle.y > position_raquette.y" la condition "vitesse_balle.y > 0" (ou < 0, selon comment sont orientés tes axes), pour que le test ne soit validé que quand ta balle touche la raquette en descente (ça éviterait d'avoir à modifier à la main sa position y, ce qui la "téleporte", même si ça ne se voit quasiment pas).

Sinon, sans ajouter beaucoup de code tu devrais pouvoir ajouter quelques sons et une musique de fond, ça rendrait le jeu plus vivant sans beaucoup d'efforts

Et juste à titre d'information (pour une prochaine fois, ce serait un changement trop important à faire ici) : pour éviter qu'un jeu tourne à des vitesse différentes selon la puissance de la machine, on calcule géneralement tous les déplacements en fonction du nombre d'images par seconde. Une autre solution, plus contraignante pour le joueur mais aussi plus simple à coder, serait de limiter manuellement ce nombre pour que le jeu ne soit pas trop rapide sur des machines puissantes, mais comme ton problème serait plutôt de la lenteur, ça ne t'aidera pas beaucoup (ça éviterait juste que le jeu tourne beaucoup trop vite sur une machine très puissante).

aussi, il est vachement gros ton fichier pour un p'tit jeu comme ça non ?

-

Merci pour tes commentaires Zephyr

Oui en effet ajouter le fait que la balle soit en descente dans la condition de collision de la raquette règlait aussi le problème
En fait au départ cette condition était présente puis quand j'ai du refaire le "moteur" de collision je ne l'ai pas remise, sans me douter de la conséquence
Mais au final je préfère la solution adoptée ici car au moins on ne voit plus la balle superposée à la palette, ça fait plus propre je trouve. La "téléportation" n'étant en effet pas vraiment visible.
Sinon c'est clair pour la musique et les sons. En fait à la base un ami musicien devait me faire de la musique pour le jeu mais il y a un gros mois il est parti vivre dans un autre pays donc j'ai du faire sans. J'ai voulu au départ chercher sur le net de la musique libre de droit pour la mettre mais je n'en ai pas eu le temps (j'ai été fort à la bourre). Les bruitages d'ailleurs n'étaient à la base là que pour le test, au final, toujours pour une raison de temps je les ai gardé, malgré qu'il ne soit pas très jolis.
Enfin, pour le frame rate il est bel et bien limité car sinon en plein écran le jeu était injouable chez moi (Athlon 64 3700+, 1Go RAM). Ce que je ne comprend pas c'est pourquoi sur ma machine il existe une différence de vitesse entre le mode fenêtré et le fullscreen, vu que la vitesse acuelle en mode fenêtré est légèrement plus basse que quand le frame rate n'était pas limité?
Mais je n'ai plus le temps pour y réfléchir. En fait le jeu est désormais en version finale, je n'y toucherai plus, sauf bug foireux à corriger mais il n'y a plus rien de trop grave à ce niveau apparament (juste deux trois trucs supportables).
En revanche si un jour je me motive à porter le jeu sur Jaguar avec les librairies C qui devraient être bientôt dispo alors je ferai en sorte qu'il soit complet au niveau sonore et parfait niveau vitesse.
Mais après le temps passé non-stop sur cette version je risque de me passer de programation pendant un bon moment (j'en ai bien marre )

Pour la taille du fichier c'est étonnant. Si je vire la table des high score (et donc l'include de fstream.h) le jeu perd 400Ko oO. Si j'employais STDIO à la place comme pour le chargement des stages il ferait 260Ko l'exe.
C'est donc uniquement fstream le coupable sur ce coup là

Au fait tu as pu retester la collision de la palette Xirius?

c'est "normal" pour la taille de ton jeu, à partir du moment où tu utilises la STL du C++ (par exemple fstream au lieu de stdio.h) ça augmente beaucoup la taille de l'executable.

C'est vraiment lent.. on s'ennuie ferme.. c'est dommage car c'est assez symapthique !!

sinon une fonction pause ceal aurait été pas mal
et un son specifique quand on perd une balle.. car c'est pas assez "marquant"

puis comme deja dis un peu plus de bruit et une musique en background ca l'aurais fait grave !

-

mh, oui, Xirius...
en fait le truc qui fait que c'est lent et chiant, c'est que la balle ne semble pouvoir rebondir qu'a deux angles differents... (enfin, 4 si on compte les deux sens droite/gauche...)

en gros, c'est pas possible de donner d'effets a la balle , et en consequence, on n'a aucun moyen de controler precisement son angle, et c'est _vraiment_ super frustrant...
pourtant c'est pas grand chose a rajouter :/

tu peux soit faire une "bonne" version, ou tu stockes en plus de la vitesse, position, etc, de la balle, une valeur qui represente son spin, et chaque rebond, suivant un coefficient de friction pour la balle et la surface touchee, va faire perdre du spin a la balle, et transferer le spin perdu pour modifier l'angle de son rebond (en fait la vitesse de la balle le long du plan d'impact), soit une version simplifiee, ou tu changes juste l'angle de rebond sur la raquette en fonction de la vitesse instantanee de la raquette au moment ou la balle rebondit dessus...
et pour la vitesse instantanee, du prends juste la position de la raquette a la frame d'avant, sa position a cette frame la, tu calcules le vecteur de deplacement, tu le divises par le temps en secondes qui separe les deux frames, et ca de donne le vecteur de vitesse "instantane" de ta raquette pour cette frame... ensuite, c'est juste une question de devier le vecteur reflechi ou la normale de reflection en fonction de cette vitesse (dans le cas de la version simplifiee), ou de calculer un spin en fonction du coefficient de friction de la palette et de la balle.
et pour que ca soit encore mieux, tu peux mixer les deux (spin _et_ deflection de trajectoire suivant la vitesse instantanee de la raquette)

(bon ca peut paraitre tordu comme ca en texte, mais en code (surtout en C++), ca prend vraiment pas grand chose...)

enfin c'est dommage, parceque c'est pas grand chose a ajouter, et ca aurait quand meme apporte un gros plus du point de vue des possibilites de jeu... (je trouve...)

ouaich sinon niveau bug plus grand chose a part que des fois la balle rebondis de façon "illogique" sur les carré (genre elle part dans le sens opposé de ce que l'on aurait pu croire)

sinon la fonction pause manque vraiment !!!

Il y a une touche pause bien sur, toutes les commandes du jeu sont dans le fichier .txt qui se trouve juste a côté de l'exe
Ha ben non, je viens de vérifier, j'ai oublié de le mettre avec, voici les commandes:

Space Ball - Commandes

Menu:
F1: jouer
F2: afficher high scores
ESC/Fermer Fenêtre: quitter
TAB: switch fullscreen

High Scores:
ESC/Fermer Fenêtre: retour au menu
TAB: switch fullscreen

Partie:
Souris: déplacements
BT Gauche Souris: lancer bille
ESC: quitter partie
TAB: switch fullscreen

Touche de triche:
F1: ajouter 1 bille (Bonus B)
F2: passer le stage (Bonus L)
F3: réduire palette (Bonus P-)
F4: agrandir palette (Bonus P+)
F5: ajouter 500 points (Bonus S)

Sinon c'est clair que le game play pourrait être bien plus sympa mais bon, j'en resterai néanmoins là.
Pour les collisions avec les briques en effet il y a de temps à autre un rebond louche, j'ai eu beau revérifier mon code plein de fois je ne comprend pas pourquoi

Pour en revenir à la vitesse qu'as-tu comme config Xirius?
Ce n'est pas qu'il soit normal pour un tel jeu de ramer même sur un P2, je suis bien conscient du manque d'optimisations de mon code mais je m'étonne quand même que tu te pleigne d'une telle lenteur. Est-ce le cas en plein écran aussi? (touche TAB) ou alors tu as un Duron 700?

Un problème pour la vitesse vient aussi de mes images. Si je met l'écran en mode couleur 8 bit le jeu gagne beaucoup en fluidité mais les couleurs deviennt immondes. Si dès le départ j'avais fait en sorte que les immages soient en couleur 8 bits cela n'aurait pas posé de problème, les couleur seraient restées belles et le jeu serait au moins deux fois plus rapide (enfin, j'aurais limité le frame rate au même niveau mais sur une vieille config ça aurait été jouable quand même).

Pour le pourquoi du C++ c'est une obligation et non un choix délibéré de ma part. Personellement je n'ai pas assez de pratique de l'orienté object pour en tirer réellement parti. Dans mon cas le seul vrai atout c'est que le code fait mieux rangé ainsi. Mais vis à vis de mes prof et du jury il fallais que j'emploie le C++ et non le C.
Le projet a été d'ailleur commencé en C, ce n'est que quand j'ai implenté les briques que j'ai tout réorganisé en Orienté Object.

-

Oui je suis d'accord avec toi. Enfin, dans ma formation j'ai eu un cours de procédual en C donc de 120h puis un cours de 120h OO en C++, donc sur papier c'est équivalent. Mais le fait est que la première moitié du cours de C on ne fait que des trucs très basiques, ce n'est qu'après cette moitié qu'on attaque des trucs plus évolués, les IO fichiers, les liste chainées, les structures...
Pour le C++ on a déjà ces bases là pour attaquer.
Bon après pour ma défense ça faisait aussi un an que je n'avais pas fait de C/C++ et en commencant le projet j'ai du bien revoir mes bases, la syntaxe, apprendre à employer la SDL, bref, ça m'a pris du temps pour me lancer vraiment.

Comme l'a dit Momotte c'est dommage qu'on ne puisse pas donner d'effets a la balle, comme dans Krytpon Egg sur ST (qui reste ma référence ). J'ai remarqué qu'on pouvait prédire dans quelle sens allait repartir la balle et à quelle vitesse en fonction de l'endroit d'où on l'a frappée avec la raquette. Si c'est à l'extrême gauche elle va partir à gauche, très vite et avec un angle fermé, si c'est à gauche elle ira moins vite sur la gauche avec un angle plus ouvert, et idem pour la droite. Pour donner de l'effet à la balle le top serait de prendre en compte la vitesse et le sens de la raquette au moment où l'on frappe la balle. Je sais pas si je suis clair

Bon sinon pour le reste no souci, tout fonctionne bien (j'ai un AMD XP2400+).

Thanks pour le comment Strider.
Oui en effet c'est ainsi que le comportemant de la balle est prévu. Je sais que c'est limité mais c'est même à petite échelle une possibilité de contrôler la balle. On peu choisir le sens un un angle large ou pas
Je sais, je sais, c'est cheap
Enfin, évidemment c'est flagrant pour un gamer. Ca devrait en revanche ne pas choquer mes profs, comme les amis à qui je l'ai montré qui ne jouent jamais à des JV
C'est sympa aussi d'avoir donné ta config, ça m'aide à situer la gourmandise du soft. Je sais que sur un Duron 750 c'est naze. Reste à voir les machines entre ce Duron et ton XP2400 +

momotte, strider, y'a un casse brique sur pc où on peut donner de l'effet à la balle, pour voir ce que ça donne comme gameplay ? ^^

(aucune idee... ^^)

-

hmm nop je crois pas, dans dx ball 2 la direction de la balle dépend de l'endroit où elle a touché la raquette, mais pas de sa vitesse au moment de l'impact