Champ de vision avec obstacles - as3

Soyez le premier à donner votre avis sur cette source.

Vue 5 604 fois - Téléchargée 636 fois

Description

Des ennemis sur la scène regardent autour d'eux pour vous chercher. Leur champ de vision tient compte des obstacles qu'ils rencontrent. S'ils vous trouvent, ils vous foncent dessus.
Ce tutoriel est une adaptation d'un tutoriel AS2 que j'ai trouvé ici (http://www.flashkod.com/codes/CHAMP-VISION-AVEC-OBSTACLE-CIBLE-TROUVER_41550.aspx).
Par rapport un tutoriel initial en AS2, j'ai adapté le code pour le passer en AS3. J'ai également inclus une gestion dynamique des ennemis. Ils sont créés par un simple array en début de code.

Conclusion :


Pour diriger votre joueur, utilisez les fléches. Vous pouvez aussi maintenir la touche SHIFT enfoncée pour courir.
J'ai beaucoup modifié ce code depuis pour un jeu que je suis en train de finaliser mais j'ai préféré mettre ce code qui est à la fois court et assez simple plutôt que de mettre un code plus avancé et plus complexe.

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Messages postés
380
Date d'inscription
mardi 29 avril 2003
Statut
Membre
Dernière intervention
28 décembre 2009

Ce code sent l'AS2 à plein nez, mais je préfère rester sur une note positive car en ce moment on peut pas dire qu'il y ai beaucoup de nouvelles sources de postées...
Je t'invite donc a regarder un peu l'AS3 en comment il s'organise. Il faut absolument se débarrasser de ses vieilles habitudes de codage AS2. Si on est à l'AS3 c'est pas pour rien !!!
Messages postés
20
Date d'inscription
mardi 15 mars 2011
Statut
Membre
Dernière intervention
14 janvier 2012

Oups, et j'oubliais je parlais de flash et pas de flash buider ou flex qui quand on crée un projet rend les choses évidentes...
Juste que dans flash on n'est pas obligé de créer un projet et on peut sans problème surcharger la classe principale spécifiée dans l'onglet propriétés de flash pro (ce qu'on voit souvent)...

Évidemment dans un autre éditeur on verra plus normalement :

//Application.as
package{
import flash.display.Sprite;
import classes.UneAppli;

public class Application extends Sprite{
public function Application(){
UneAppli.main();
}
}
}
//et dans UneAppli.as
package{
public class UneAppli{
public static function main(...args):void {
//code
}
}

}

// vite fait dans le browser... mais ça doit être juste.
un constructeur si nécessaire (pas forcément, vu que en théorie on aura des propriétés et méthodes static)

Désolé de ne pas avoir été clair là-dessus, j'ai remarqué ça ce matin!!!
Sinon oui, le commentaire n'avait pas sa place et au lieu d'AS4 je devais plutôt dire prochaine version de flash (qui sera peut-être AS4) :)
Messages postés
20
Date d'inscription
mardi 15 mars 2011
Statut
Membre
Dernière intervention
14 janvier 2012

Le bout de code (très maso je l'avoue!) on peut l'oublier en effet, c'et juste une façon d'illustrer une idée.
C'est long et inutile mais AS4 pourrait être plus strict afin d'éviter certaines choses.
Ou alors dans un environement de travail tomber enfin d'accord sur certaines habitudes à respecter pour ne pas avoir trop de mauvaises surprises lors de modifs un peu brutales quand on n'est pas là... :)
Il y a de plus en plus de graphistes qui se mettent à toucher à du code et ce n'est pas souvent très réutilisable, voir par moments assez cata ;)
Donc je sautais juste sur l'occasion pour dire qu'en effet je ne critiquais pas la source mais que j'étais d'accord avec le principe de "juste une traduction pour AS3", chose qui peut être assez gênante en prod.
Bon, pardon donc et autant pour moi :)
Messages postés
6146
Date d'inscription
dimanche 21 décembre 2003
Statut
Modérateur
Dernière intervention
4 septembre 2013
10
En AS3, langage de typage fort, le typage est synonyme de performance ... il n'y a qu'à comparer un Vector et un Array sur de gros traitements pour s'en convaincre...

Peg'
Messages postés
465
Date d'inscription
mardi 17 avril 2007
Statut
Membre
Dernière intervention
4 mai 2013
1
Personnellement, je pense que c'est un avantage d'avoir la liberté ou non de typer.
Parfois il est meme indispensable de transtyper.
Le tout est d'avoir conscience de ce que cela implique ou non de le faire.

Quant au sérieux d'un language, ca me fait doucement rire, c'est plutot un qualificatif que l'on utilise pour un humain. Sans doute est-ce une marque de ce meme manque chez ces auteurs.

Quant l'obligation d'étendre (directement ou non) la class main avec un displyObject, je la comprend comme justement comme son affectation sur la scene permettant ainsi d'obtenir le "Stage".
Afficher les 15 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.