Flash Shmup Engine [Standby...]

[Dimebagplan]

Ouais j'espère que ça va le faire !!!!!!!!!!!!!!!!
L'incorporation de Bullet ML étais vraiment trop complexe, et aussi difficile à adapté sur mon moteur.

J'ai donc décider de créer moi même le Bullet Editor, comme ça je garde le contrôle partout ^^

Des précisions sur Bullet Editor:

Angle : En général, 180 ou 360 °;
Bullet Number : Nombre de bullets envoyé par chaque séries;
Bullet Speed : Fais varier la vitesse des bullets.
Turn : Fait tourner l'ensemble des bullets (valeur en °)
Loops : Nombre de boucles par séries;
Interval : Intervalle entre chaque séries (en FPS) ;
60F=1sec

Si vous trouvez des pattern intéressants et pas trop gourmand en ressources (pensez aux ordi moins puissants) n'hésitez pas à les noté quelques part et donnez leurs un nom.


D'autres versions plus complètes du Bullet Editor sont à venir
Amusez vous bien ^^

[raphael]

Epatant !

2 remarques:
- le paramètre de vitesse est assez peu subtil. A 1 c'est du patern très lent, à 2 c'est déjà assez rapide.
- impression ou pas, je ne serais dire, mais c'est comme si les boulettes ralentissaient au fur et à mesure de leur déplacement.

[Radigo]

- impression ou pas, je ne serais dire, mais c'est comme si les boulettes ralentissaient au fur et à mesure de leur déplacement.

Certainement les FPS qui tombent quand on ajoute des boulettes.

Je ne dis pas grand chose à propos de ce shmup editor, mais je suis super à l'écoute.

[Fu]

On pourra jouer en jouant avec un vrai vaisseau et en faisant des vraies esquives avec ce bullet editor ?

[tam]

manque un compteur de boulettes à l'écran qu'on tâte un peu des performances du moteur

[Dimebagplan]

Coucou.

Quelques réponses :

- le paramètre de vitesse est assez peu subtil. A 1 c'est du patern très lent, à 2 c'est déjà assez rapide.

Oui, je pourais diviser la valeur par dix dans mon programme, ce qui veux dire qu'on pourrais aller de 1 à 30, par exemple.

ceci dis, il t'es possible de rentrer une valeur décimale "1.5", "2.3", "0.04".

- impression ou pas, je ne serais dire, mais c'est comme si les boulettes ralentissaient au fur et à mesure de leur déplacement.

Comme l'a dis Radigo, il ce peux que le nombre de fsp descende et conduise à un ralentissement.

On pourra jouer en jouant avec un vrai vaisseau et en faisant des vraies esquives avec ce bullet editor ?

Hum, je ne sais pas encore comment va évoluer le bullet editor, mais je pense qu'il servira uniquement à créer ses pattern et les sauvegarder.
Mais un petit vaisseau pour tester si le pattern est trop simple ou trop complexe pourrait être interessant.

manque un compteur de boulettes à l'écran qu'on tâte un peu des performances du moteur

Le programme lui est vraiment clean, je dirai plutôt que tu va tester les performances de ton propre ordi


Par exemple, sur mon PC actuel qui n'est pas une fleche mais pas une bouze non plus, il gère a peu près "120" bullets, Et cela, sans aucuns scrolling de décors ni rien d'autre...

Mon Mac Book Pro par contre, en gère presque le double sans même lagger...

Je vais ajouter le compteur

Mais il faut savoir une chose, Flash à la base n'est vraiment pas optimiser pour les jeux !
Malheureusement il est victime de son succès, il suffit de voir les millions de jeux flash qui tournent sur le net...

C'est vraiment dommage

[raphael]

Coucou.

Quelques réponses :

- le paramètre de vitesse est assez peu subtil. A 1 c'est du patern très lent, à 2 c'est déjà assez rapide.

Oui, je pourais diviser la valeur par dix dans mon programme, ce qui veux dire qu'on pourrais aller de 1 à 30, par exemple.

ceci dit, il t'es possible de rentrer une valeur décimale "1.5", "2.3", "0.04".

Oui j'avais remarqué. Mais avoue que quand sur une échelle de 1 à 10 le réglage moyen varie d'un quart de point autour de 1,5, c'est que l'ecelle n'est pas idéale.

Enfin bon c'est juste un détail.

- impression ou pas, je ne serais dire, mais c'est comme si les boulettes ralentissaient au fur et à mesure de leur déplacement.

Comme l'a dit Radigo, il se peut que le nombre de fps descende et conduise à un ralentissement.

Peut être que c'est ça. En tout cas ça reste bien fluide sur mon iMac même en chargeant méchamment le pattern. Bravo !

[tam]

Mais il faut savoir une chose, Flash à la base n'est vraiment pas optimiser pour les jeux !
Malheureusement il est victime de son succès, il suffit de voir les millions de jeux flash qui tournent sur le net...

C'est vraiment dommage

c'est ça qui est bon !
évidemment flash est super consommateur de CPU, n'accède pas à des primitives comme directX mais c'est pas pour rien qu'il rencontre un tel succès, on maquette en quelques heures un jeu, on l'aborde aussi bien en tant que graphiste qu'en tant que codeur, il est fort d'une communauté qui fait rêver n'importe quel click 'n play, il se déploie sur un paquet de plateformes no sweat.... bref je trouve qu'il mérite qu'on fasse quelques efforts d'optim'.

d'autant plus qu'elle est possible, faut voir les moteurs de shoot sorti ces derniers temps en actionscript, ça rigole pas. les tests qu'a fait kenta cho prouve bien qu'on peut faire tourner du manic dans une page web !

j'ai vu des moteurs de particules sous flash animer 40 000 particules en rotation 3D... évidemment je souhaite bonne chance à celui qui veut gérer les collisions à chaque frame mais tu vois qu'il y a de la place pour faire du lourd

[Androïde]

on maquette en quelques heures un jeu, on l'aborde aussi bien en tant que graphiste qu'en tant que codeur

Je t'avouerai que j'ai abandonné Flash à sa version 5 car il devenait beaucoup trop complexe et trop orienté programmeur. J'ai attendu que Microsoft sorte son concurrent en version plus WYSIWYG et j'attend tjs.

[Dimebagplan]

on maquette en quelques heures un jeu, on l'aborde aussi bien en tant que graphiste qu'en tant que codeur

Je ne serais pas aussi optimiste que toi sur ce point ^^
Effectivement il y à une pléiade de jeux Flash qui sont sorties, mais combien sortent du lot ?

Il y en à très peu !

Aussi, avec l'as3, le faussé s'est encore creusé entre les développeurs et les graphistes.
Il suffit d'aller getter un coup d'œil sur les forums de Flash pour vérifier ce phénomène.

Lors du rachat de Flash par Adobe, en développant l'As3 (Action Script 3) (Le langage de Flash.)

Ils ont oublier ce qui à fais le succès de Flash, le fait qu'un graphiste puisse coder sois même.
Aujourd'hui c'est loin d'être simple, si on veux faire quelque chose d'assez avancé.

d'autant plus qu'elle est possible, faut voir les moteurs de shoot sorti ces derniers temps en actionscript, ça rigole pas. les tests qu'a fait kenta cho prouve bien qu'on peut faire tourner du manic dans une page web !

Le BulletML de Kenta Cho, fais autant lagger mon ordi que le Bullet Editor que j'ai développer.

Des que je dépasse les 150 Bullets, c mort.
Surtout si j'agrandis la fenêtre !

j'ai vu des moteurs de particules sous flash animer 40 000 particules en rotation 3D...

Ces particules sont faites grâce à des vecteurs, et étant donné que Flash gère de mieux en mieux les calculs mathématiques et la rapidité d'exécution, c'est relativement normal.

Le problème c'est que la, dans un shmup, on à affaire à des images bitmap !
Elles ont aussi très souvant de la transparence, ce qui est loin d'être un atout pour l'optimisation dans Flash.
Les images bouffent énormément de CPU comme tu l'as dis.

Persos, je n'ai encore j'amais vu de gros shmup tourner en plein écran fais avec Flash...

Mais comme toi, je pense qu'il y à quand même moyen de faire du lourd !
Je pense vraiment que Flash à des possibilités vraiment intéressantes !
Le fait de réunir le code et le graphisme dans un seul et unique environnement c'est vraiment excellent !

Enfin moi j'adore

[Dimebagplan]

Salut à tous !

J'ai une question à vous poser sur les vaisseaux qu'on pourra implémenter.


En effet il pourrait vraiment être cool de pouvoir choisir parmi une 50ène voir 100ène de vaisseaux qu'on choisirai dans une bibliothèque énorme (façon Mugen).

Mais pour la programmation ça risque d'être un casse tête énorme, je m'explique :

Il existe autant de vaisseaux que de façon de tirer dans les shmups.
Entre les autofire, les charges d'énergies, les bullet simple, les lasers, les forces qui s'ajoutent à votre vaisseau, sans compter les jeux ou on contrôle le vaisseau avec 6 boutons !

Bref, Comment gérer tout ça ?

Déjà je voulais limité l'utilisation du soft à 2 boutons.
A et B par exemple.
Aussi, limité les options à : Power Up, et Bonus.

Qu'en pensez vous ?

Est-ce que ça fout tout en l'air si les vaisseaux ont tous le même genre de tirs ?

Merci pour vos avis.
@+

[folkN]

Tu proposes pas les bonus cachés qui ouvrent des loops et autres boss eux aussi cachés ?

(non je déconne ^^)

Pour les tirs, bah c'est toujours un peu pareil.

"Le plus simple" pour nos tirs, c'est d'avoir deux paramètres.
- Une liste de "skin" pour le shoot (ça permet de soit donner un effet lazer, soit bombe etc...)
- Le type de shoot (exemples : tir tout droit façon Type A sur les CAVE, tir en diagonale façon le type B/C sur les CAVE)

ça permet un peu de diversité.... Bon par contre je sais pas du tout si c'est gérable pour toi d'avoir plusieurs skins de tir, puisque ça implique une gestion des collision/hitbox différente... ?

[raphael]

Je milite pour 3 boutons.
L'un d'eux pouvant servir d'autofire quand il n'a pas de fonction plus sophistiquée.

De même pour les options, il en faudrait plutôt 3:
- power up
- bonus
- bombe (les shoots sans bombe c'est bien ce qu'il y a de plus rare)

[Androïde]

Est-ce que ça fout tout en l'air si les vaisseaux ont tous le même genre de tirs ?

Disons que ça limite énormément les possibilités. Mais tu peux toujours projeter de faire plus tard un 2nd moteur de jeu qui permette de gérer plus que 2 boutons.

[raphael]

Pour les modes de tirs et de jeu un bon point de départ c'est la distinction proposée par Kent Cho pour rRootage:

- How to play.

- Movement Arrow key / Joystick
- Laser [Z] / Trigger 1, Trigger 4
- Special [X] / Trigger 2, Trigger 3
- Pause [P]

You can select the game mode from 4 types.


. Normal mode
This is the standard game mode.
Your ship becomes slow while holding the laser key.
- Special -> Bomb
The bomb wipes enemyies bullets.
The number of bombs are displayed at the right-down corner.

. PSYvariar mode
As your ship grazes a bullet,
the graze meter(displayed at the right-down corner) increases.
When the graze meter becomes full, the ship becomes invincible for a while.
- Special -> Rolling
This movement widen the range that the ship can graze.
While holding this key, the ship becomes slow.
If you want to move faster, tap this key.

. IKAruga mode
Your ship has two attributes, white and black.
All bullets also have these attributes,
and your ship can absorb bullets that has the same attribute.
Absorbed bullets are changed into lasers automatically.
- Special -> Attribution change
Change your ships attribute.

. GigaWing mode
Your ship can use the reflector.
The reflector reflects bullets around your ship.
- Special -> Reflector
To use the reflector,
you have to hold this key until
the reflector meter(displayed at the right-down corner) becomes empty.
You can use the reflector only if the reflector meter displays 'OK'.

Là c'est un système à 2 boutons (qu'on peut même réduire à un seul pour la variante Mars Matrix des jeux à la GigaWing), mais il est plus simple et plus classique d'uiliser un bouton séparé pour la bombe, donc 3 boutons pour les modes PSY, IKA et GW. Quant au mode dit normal, en fait c'est du Cave, et l'évolution de ces jeux ces dernières années à mené uniquement à des systèmes à 3 boutons au moins (le 3ième bouton étant parfois un simple auto-fire, mais plus souvent dédié à une fonction spéciale, type tir secondaire, mode ralenti, mode hyper, changement de formation ou d'arme, etc).

[Dimebagplan]

Tout d'abord, merci à tout ceux qui s'intéresse de près ou de loin au projet et qui participent à l'activité du thread.

Votre avis de shmuper aguerri m'est vraiment indispensable !

En effet, étant donné qu'on va voir droit à des vaisseaux qui viennent d'un peu n'importe quel jeu, des bullets, laser et j'en passe, si je ne définie pas un minimum de règles il est clair que ça peux vite devenir un bordel monstre ^^

Je vais analyser vos commentaires et faire une petite synthèse.

J'essaierais de vous faire des propositions dans les jours à venir.

Bon par contre je sais pas du tout si c'est gérable pour toi d'avoir plusieurs skins de tir, puisque ça implique une gestion des collision/hitbox différente... ?

Au moment ou je pensai que tout ça allais être quasiment impossible, je viens de trouver une class As3 pour Flash qui détecte les collisions au pixel !!
Énorme le truc !
D'après les premiers test ça marche du tonnerre !
Le seul truc c'est que je ne sais pas si cette classe est fiable a long terme...

On verra bien !
@+


[EDIT]
Au fait, j'ai transformer le moteur pour un shoot vertical. J'ai finalement opté pour cette solution.
[/EDIT]

[Joe_Chip]

Au moment ou je pensai que tout ça allais être quasiment impossible, je viens de trouver une class As3 pour Flash qui détecte les collisions au pixel !!

attention avec les tests de collision au pixel, pour des tirs ça risque de ramer à mort dès quil y aura un peu de bazar à l'écran. d'habitude on utilise plutôt des bounding box pour ça.

[raphael]

Pourquoi ce limiter au vertical ?
Ca ne devrait pas poser trop de problème de proposer les 2 directions, non ?

attention avec les tests de collision au pixel, pour des tirs ça risque de ramer à mort dès quil y aura un peu de bazar à l'écran. d'habitude on utilise plutôt des bounding box pour ça.

Pareil, ça me fait peur.

[Dimebagplan]

Pourquoi ce limiter au vertical ?
Ca ne devrait pas poser trop de problème de proposer les 2 directions, non ?

En effet, c'est plus pour le moment que j'utilise ça, mais passer de l'un à l'autre ne seras pas compliqué.

attention avec les tests de collision au pixel, pour des tirs ça risque de ramer à mort dès quil y aura un peu de bazar à l'écran. d'habitude on utilise plutôt des bounding box pour ça.

Pareil, ça me fait peur.

Pas d'inquiétude. J'utilise déjà des bounding Boxes pour mes collisions.

Voici, l'exemple d'un laser, Si on effectuent une simple rotation, voila à quoi va ressembler la bounding box.

Bien sur il existe différents type de Bounding boxes (qui sont plus moins complexe à mettre en place), mais voici l'exemple type.

Heureusement, je détecte les collisions avec les bounding Box dans un premier temps, et Seulement dans un second temps, Si et seulement SI un Objet rentre en collision avec une bounding Box, je fais mon deuxième test de collision au pixel.

De plus je peux choisir la marge pour une plus ou moins grande précision.
Ce qui me permet de gagner en optimisation tout en étant très précis !

Voila pour les précisions !
@+

[Joe_Chip]

Ha oui d'accord, tu veux faire comme ça.

Alors en fait tu peux complétement te passer de la collision au pixel, qui même dans ton exemple te sera beaucoup trop couteuse en temps de calcul (surtout sur un gros sprite comme ça), en utilisant quand même juste les bounding box.

Dans ton exemple de laser à 45°, il faut créer ta box pour qu'elle encadre ton laser en position verticale, ensuite tu lui appliquera la même rotation à 45° que sur ton sprite de laser, elle l'encadrera toujours parfaitement.
Le truc à partir de là c'est d'utiliser les maths pour ton test de collision: il n'y a pas d'intersection entre 2 polygones s'il existe une ligne qui les separe.

Pour trouver si cette ligne existe il faut alors projeter les polygones sur les axes perpendiculaires à chacuns de leurs côtés, et voir si les projections se superposent.
Si pour au moins un des côtés il n'y a pas superposition, alors la ligne existe, donc => pas d'intersection, donc => pas de collision.

En schema ça ressemble à ça:


J'explique pas très bien mais en vrai ça donne un algorithme tres simple et peu gourmand (dans la mesure où nos polygones sont juste des box), qui permet de se passer completement du test au pixel et peut apparemment aussi prédire les collisions (ça j'ai jamais essayé).

Regarde là: http://www.codeproject.com/KB/GDI-plus/ ... ision.aspx
et là: http://gpwiki.org/index.php/Polygon_Collision ce sera plus clair je pense

en esperant que ça aide

[Dimebagplan]

Coucou, merci pour l'exemple apporté

De toute façon, la classe de detection au pixel est loin d'être parfaite, et possède encore quelques bugs.

Donc, de toute façon je vais me créer une classe qui utilise les Maths pour la detection de collision.

Finalement c'est ce qu'il y à de mieux.
Et en effet ça bouffera moins de ressources.

Les articles apportés sont intéressants.

De toute façon un shmup de qualité, ça met vraiment du temps à ce faire.
Mais bon, en même temps c'est intéressant.
C'est pour ça que je le fais ^^

@+ !

[Dimebagplan]

--------------------------------------------------------
////// VERSION 0.5 /////////////////////
http://perso.numericable.fr/dimebagplan ... 5/fse.html
--------------------------------------------------------

La 0.5 !

La, le jeu commence à devenir intéressant ! (je prend presque du plaisir à y jouer)

Par contre, ya déjà des signes de ralentissement sur mon PC, et vous ?

Quelques remarques /b]

-Des fois, le jeu ne ce lance pas du premier coup, si dans les premières secondes vous ne voyez pas de loading, faites un refresh (F5)

-Si vous avez des problèmes d'affichages (j'en ai eu sur mon MAC).
essayer de remplacer fse.html par fse2.html (version plus petite).

-Le chargement est long...


Barre d'espace pour tirer (Auto Fire).
Bon jeu.

[folkN]

wah c'est vraiment bien !

J'aimerais vraiment savoir en faire autant

Par contre quid des droits sur les sprites utilisés ?
(et de l'endroit où tu les chopes ? )

[Yoshiki]

Mon premier message sur ce topic pour t'encourager dans ton travail.
C'est vraiment sympa ce que tu fais
J'ai suivi les évolutions depuis la première version et ça avance plutôt bien !

Petite remarque concernant cette dernière version : Chez moi, les déplacements en diagonale ne fonctionnent pas lorsque je reste appuyé sur le bouton de tir (Sauf le déplacement en diagonale haut/droit qui fontionne toujours).

Allez hop ! Un nouveau 1CC (et même one-life) à mon actif !
Hein ? Quoi ? Ca compte pas ?

[folkN]

Pour info chez moi toutes les diags fonctionnent avec le tir.

Peut-être un soucis avec ton clavier ?

[Yoshiki]

Peut être. Il faudrait voir si d'autres personnes rencontrent le même problème que moi.

En tout cas, ça ne vient pas de mon navigateur.
Après avoir testé sur Opera, je viens de tester sur IE et c'est idem.

[tam]

ça vient de ton clavier, dimebagplan devrait brancher ses directions sur ZQSD façon fps pour rencontrer moins de soucis, certains claviers sont un peu pénibles avec les flèches de direction.

une remarque : j'ai de gros soucis de freeze toutes les X secondes, je suppose que c'est lorsque le flash player lance son garbage collecting, tu devrais surveiller très précisément l'état de ta mémoire utilisée d'autant plus que si le problème apparait rarement dans un test sur le standalone player, c'est beaucoup plus falgrant une fois dans la navigateur (surtout firefox !)

sinon ça commence à avoir vraiment de la gueule ! chouette début !

[raphael]

Pas une seule touche qui marche chez moi.
(c'est bien flèches et espace ?)

Ma config: iMac 2.4 Ghz Core 2 Duo / Mac OS 10.5.6 / Safari 3.2.1 / Flashplayer 10

[psychogore]

franchement sympa comme demo

le bullet editor est bien fendard aussi, par contre, c'est un peu dommage qu'on ne puisse pas choisir la direction de depart de l'eventail (si on met angle à 45° il tire vers le coin à droite).

[Xesbeth]

Petite remarque concernant cette dernière version : Chez moi, les déplacements en diagonale ne fonctionnent pas lorsque je reste appuyé sur le bouton de tir (Sauf le déplacement en diagonale haut/droit qui fontionne toujours).

Pareil, la diagonale haut droite ne fonctionne pas quand je tire, par contre toute les autres diagonales fonctionnent.