Source de l'article : csdn Auteur : Chen Wanfei
À propos de l'auteur
Chen Wanfei, un homme, est titulaire d'un baccalauréat en mathématiques et en logiciels de l'Université Central South. Il était programmeur principal et analyste système chez Beijing Great Wall Software. Il possède une vaste expérience dans le développement de j2se et de j2ee. Je travaille actuellement sur la recherche j2me. Il peut être contacté à [email protected]
résumé
Cet article donne un plan de conception pour un jeu Tetris basé sur MIDP1.0 et donne le code source complet d'implémentation. La plus grande caractéristique du jeu est l'adaptabilité de l'écran. Quelle que soit la taille de l'écran des différents téléphones mobiles et PDA, le jeu peut toujours obtenir le meilleur effet d'affichage. Le jeu a été testé sur quatre émulateurs du kit d'outils sans fil J2me 2.1.
Avis de non-responsabilité : ce code de jeu provient à l'origine d'un projet open source japonais (voir référence 1) et a été considérablement modifié par l'auteur.
Voici quelques captures d'écran du jeu :
conception
1. Processus opérationnel
Le processus de fonctionnement de ce jeu est très simple. Une fois que l'utilisateur a démarré le MIDlet, il entre dans l'écran principal du jeu et l'écran commence à afficher l'écran de bienvenue. Une fois que l'utilisateur a appuyé sur le bouton [Démarrer], il peut commencer à jouer au jeu. Lorsque l'utilisateur souhaite faire une pause, il appuie à nouveau sur le bouton [Démarrer] et le jeu est mis en pause s'il appuie à nouveau sur le bouton [Démarrer]. en pause, le jeu continue de fonctionner. Chaque fois que vous appuyez sur le bouton [Exit], le MIDlet de jeu sera terminé.
L'organigramme de l'écran de jeu est le suivant :
2. Algorithme
La conception de jeux MIDP utilise essentiellement un thread ou une minuterie pour générer des événements de redessinage, et utilise des threads et des entrées utilisateur pour modifier l'état du jeu. Ce jeu ne fait pas exception. Après le démarrage de MIDlet, un fil de redessin est immédiatement généré, qui dessine l'écran toutes les 50 ms. Bien sûr, il existe certaines mesures d'optimisation lors du redessin. Tous les pixels de l'écran n'ont pas besoin d'être redessinés, mais il existe des sélections, telles que les objets qui tombent qui ont été corrigés sur la toile de jeu (il existe 7 types d'objets qui tombent au total). , composé de 4 Composé de petites briques, chaque objet qui tombe a une couleur fixe et peut être tourné vers le haut, le bas, la gauche et la droite, il n'est donc pas nécessaire de le redessiner. Le canevas du jeu est un CommandListener qui peut accepter les commandes clavier de l'utilisateur et contrôler les actions de gauche, de droite, de bas et de rotation de l'objet qui tombe. Le contrôle du flux de l'ensemble du jeu se reflète dans la méthode paint() de l'objet canevas du jeu. paint() dessine l'écran de jeu actuel en fonction de l'état actuel du jeu. L'écran d'accueil et l'écran Game Over sont assez simples à dessiner. Dessiner l'écran de pause du jeu est également assez simple, il suffit de définir un indicateur pour que lorsque paint() est exécuté, il ne soit pas nécessaire d'effectuer une action de redessinage. Pour dessiner l'écran lorsque le jeu est en cours, l'objet qui tombe doit être dessiné à la position actuelle de l'objet qui tombe. Avant de dessiner l'objet qui tombe, déterminez si l'objet qui tombe peut encore tomber. S'il peut tomber, laissez-le tomber d'un espace, puis dessinez-le si l'objet qui tombe ne peut plus tomber, déterminez si le jeu est en état Game Over. il est en jeu. Si le jeu est à l'état Over, définissez l'état du jeu sur Game over, de sorte que le canevas dessine l'image Game Over la prochaine fois qu'il est redessiné. Si le jeu n'est pas à l'état Game Over. , corrigez les objets qui tombent et vérifiez les objets qui tombent sur la toile de jeu en même temps. Vérifiez toutes les lignes situées sous la ligne actuelle pour voir si la suppression de la ligne est requise, effacez les données de la ligne supprimée sur le jeu. carte, puis dessinez la ligne supprimée avec une couleur d’arrière-plan. Initialisez ensuite un nouvel objet qui tombe et dessinez ce nouvel objet qui tombe. L’organigramme de la méthode de peinture est le suivant :
3.Structure des données
Ce jeu implique les structures de données suivantes.
aire de jeu
La zone de jeu fait partie de l'écran du téléphone portable ou du PDA. La zone est un carré et la longueur du côté doit être divisible par 16 (car la zone de jeu russe est exactement un carré de 16 petites briques de long et 16 petites briques). large). Cette zone doit être centrée sur l’écran, tant horizontalement que verticalement. La zone de jeu est divisée en 2 parties horizontalement, une partie mesure 12 petites briques de large pour afficher le conteneur de jeu, et l'autre partie mesure 4 petites briques de large pour afficher le prochain objet qui tombe et le score.
petites briques
Les petites briques font partie du conteneur de dépôt et de jeu. Apparaît sous la forme d'un carré dont la longueur du côté correspond à 1/16 de la longueur du côté de l'aire de jeu. Lorsque chaque petite brique est dessinée, 1 pixel sera laissé sur les quatre côtés et dessiné en blanc ou en gris afin qu'il y ait un espace entre les briques. Chaque petite brique possède également un identifiant, allant de 1 à 8. Nous pouvons utiliser un tableau de couleurs (appelé BRICK_COLORS dans le programme) pour stocker ces 8 couleurs. Si l'identifiant d'une certaine petite brique est 3, alors la couleur de la petite brique est BRICK_COLORS[3-1].
objet qui tombe
La chute est essentiellement un carré composé de 16 petites briques. Il existe un total de 7 types d'objets qui tombent, tels que ceux en forme de « champ », en forme de « L », etc. Il existe 4 variations de rotation pour chaque objet tombant. Chaque objet qui tombe a un identifiant allant de 1 à 7. Car pour un objet qui tombe, sa couleur est fixe. Nous pouvons également utiliser la valeur d'indice de cette couleur dans le tableau BRICK_COLORS plus 1 comme identifiant de l'objet qui tombe.
Par exemple, l'objet qui tombe en forme de « L » a un ID de 3 et sa variation est :
Alors, quelle structure de données est utilisée pour stocker un objet en chute ? Prenons un objet en chute en forme de « L » comme exemple pour illustrer :
Étant donné que chaque objet en chute a quatre états, nous pouvons envisager d'utiliser un tableau de longueur 4 pour stocker les quatre états d'un objet en chute. Chaque élément du tableau représente un état de l'objet en chute. Alors, que faut-il utiliser pour représenter un certain état d'un objet en chute ? Comme le montre la figure ci-dessus, il est plus approprié d'utiliser un tableau bidimensionnel 4X4 pour stocker l'état d'un objet en chute. Là où des briques colorées apparaissent, la valeur est 1, et là où il y a seulement une couleur de fond et pas besoin de dessiner, la valeur est 0. Par conséquent, les quatre états de l’ensemble de l’objet tombant en forme de « L » peuvent être représentés par un tableau tridimensionnel :
protégé int blockpattern3[][][] = {
{{0, 1, 0, 0}, {0, 1, 0, 0}, {0, 1, 1, 0}, {0, 0, 0, 0}},
{{0, 0, 0, 0}, {0, 1, 1, 1}, {0, 1, 0, 0}, {0, 0, 0, 0}},
{{0, 0, 0, 0}, {0, 1, 1, 0}, {0, 0, 1, 0}, {0, 0, 1, 0}},
{{0, 0, 0, 0}, {0, 0, 1, 0}, {1, 1, 1, 0}, {0, 0, 0, 0}}
} ;carte du jeu
La carte du jeu est utilisée pour stocker des tuiles fixes sur le conteneur de jeu. Le conteneur de jeu mesure 12 petites unités de briques en largeur et 16 petites unités de briques en hauteur, y compris les deux murs gauche et droit et le fond du conteneur en dessous. Ainsi, un tableau bidimensionnel 16X12 (appelé mapdata dans le programme) est utilisé pour stocker les briques fixes. Si mapdata[i][j]=k(k!=0). Cela signifie qu'il y a une petite brique fixe sur la ligne i et la colonne j du conteneur de jeu, et la valeur de couleur de la petite brique est BRICK_COLORS[k). -1] Si k=0, cela signifie qu'il n'y a pas de briques dans la ligne i et la colonne j.
Par conséquent, pour la durée d'exécution du jeu suivante, la valeur de mapdata est {{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0 , 0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0 , 0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0 , 0,0,0,0,0,0,8}
{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8} {}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0, 8}
{8,0,0,0,0,0,0,0,0,1,1,8}{8,0,0,0,0,0,0,0,0,1,1,8} {8,0,0,0,0,0,7,7,5,1,1,8}{8,0,5,0,0,7,2,5,5,1,1,8}
{8,8,8,8,8,8,8,8,8,8,8,8}}
Code source et code exécutable
Il y a 3 fichiers au total : src.rar, ketrisgame.jad, ketrisgame.jar Remarque : src.rar contient tous les codes sources. Il existe également des fichiers de ressources requis pour le programme exécuté dans ketrisgame.jar. Après avoir installé wtk2.1, placez ketrisgame.jad et ketrisgame.jar dans le même répertoire (notez que le chemin du répertoire ne peut pas contenir de caractères chinois ni d'espaces), double-cliquez sur le Fichier ketrisgame.jad, vous pouvez exécuter le jeu dans l'émulateur.
Références
http://www.javadrive.jp/j2me/game/3/index.html
<j2me en quelques mots>
<Introduction à la programmation Java pour téléphones mobiles/PDA>