Salutations à tous! Aujourd'hui, je voudrais parler de la façon d'implémenter la gestion des glissements dans un projet de jeu pour Android sur le moteur Godot.Je m'appelle Peter et je suis l'un des utilisateurs actifs du moteur de jeu Godot Engine.Dans le segment de langue russe, il y a une énorme pénurie de matériel sur cet outil, ce qui me surprend beaucoup, car il est l'un des moteurs de jeu à la croissance la plus rapide.Bien sûr, il est à bien des égards inférieur à des moteurs tels que Unity, UE, etc., et vous ne ferez pas de jeu de classe AAA dessus.Toutefois! Il est gratuit (complet), multiplateforme (complet), et son poids est d'environ 60 mégaoctets, par opposition à la même unité.Le moteur fonctionne sur la plupart des appareils, même si ces derniers proviennent d'une ligne très économique. Également «prêt à l'emploi», il est déjà russifié, dispose de tous les outils nécessaires à bord, ne nécessite pas de logiciel supplémentaire et ne consomme pas toute la RAM en cours d'exécution.J'ai déjà vu quelques articles sur Habré à ce sujet, et c'est très petit, car il est si sympathique pour le développeur que c'est une grosse omission de le dépasser et de ne pas l'essayer.Le sujet de cet article est l'implémentation de la gestion des swipes (gestes) dans un projet Android.En général, l'expérience de mon utilisation du moteur est assez étendue et si le sujet obtient une réponse, je peux organiser un cours de formation complet. Par ce post, je veux au moins attirer votre attention sur le moteur.En tant que langage de programmation, vous pouvez à nouveau utiliser deux options: GDScript et C #. J'utiliserai le premier.L'interface de l'éditeur principal ressemble à ceci:
vous pouvez y travailler simultanément avec 3D, 2D, des scripts et en général tout ce dont un développeur peut avoir besoin.Le moteur utilise une approche dans laquelle votre jeu est un ensemble de scènes imbriquées les unes dans les autres. Et il peut y avoir une certaine confusion, car j'utilise le terme «scène» pour les nœuds qui ne sont que des scènes de jeu (situations, fenêtres, états de jeu (menus, jeux, etc.)), et pour d'autres cas j'utilise le terme "Prefab" emprunté à Unity.Étant donné que dans cet article, je considérerai un cas particulier, je ne développerai pas certains sujets. Si quelque chose n'est pas clair, il y a des commentaires.Donc, la scène principale de la démonstration, nous aurons un jeu.Sa structure ressemble à ceci:
Le nœud racine du jeu stocke imbriqué en lui-même:- monde, - stocke des données de niveau en lui- - niveau, - un ensemble d'objets d'environnement (blocs, anneaux, obstacles)- - joueur, - objet joueur- - InterpolatedCamera, - lisse la caméra qui surveille l'interface - gui, - du joueur ne sera pas impliquée. Lesnoms des objets et de la structure sont arbitraires et ce n'est qu'un cas particulier.Près de certains objets, vous pouvez voir des icônes indiquant que cet objet est un préfabriqué (scène imbriquée) et qu'un script peut également y être ajouté.Donc, en cliquant sur l'icône «script», nous entrons dans l'éditeur de script, en fait, le mode de fonctionnement du moteur change simplement.
Dans ce mode de fonctionnement, vous pouvez modifier le comportement des objets. En fait, dans ce cas, c'est un script de l'objet monde qui, lors du chargement d'un objet dans le jeu, définit l'objet caméra (InterpolatedCamera) définit la cible du suivi.extends Spatial
func _ready():
$InterpolatedCamera.target = '../player/camera'
Syntaxiquement, GDScript est similaire à Python. Vous pouvez suivre une brève formation sur GDScript en russe ici: Livre GDScriptAvec l'objet monde, c'est clair, il définit simplement la cible de la caméra pour le suivi. L'objet suivant (déjà un enfant du monde) est le niveau. Sa structure ressemble à ceci:
En fait, ce sont simplement des objets arrangés avec des propriétés physiques qui n'ont pas de scripts ou de comportement. En plus des objets "cellule". Ce sont des anneaux qui tournent et disparaissent au contact de l’objet du joueur.L'objet joueur est le plus intéressant en ce moment, qui contient la logique de contrôle de balayage pour les écrans tactiles.Ce préfabriqué ressemble à ceci: l'
objet racine a un script, que nous verrons un peu plus tard.Considérons d'abord les objets imbriqués.- camera, — , , . player.
- CollisionShape, — . «» . , , . .
- MeshInstance, — . , . Blender 3D , .
- Tween, . .
Eh bien, considérons maintenant le script lui-même dans l'objet racine. Il s'avère être le plus volumineux de tout le "jeu".
Eh bien, sa description et son décodage.
extends KinematicBody
const GRAV = 0.5
const SPEED = 2
const SWIPE_SPEED = 30
const JUMP_SPEED = 10
onready var ball = $MeshInstance
onready var tween = $Tween
var vel = Vector3()
var swipe = ''
func _ready():
pass
func _physics_process(delta):
vel.y -= GRAV
vel.z = -SPEED
ball.rotate_x(-delta * SPEED * 2)
if swipe && swipe != 'swiped':
if swipe == 'up' && is_on_floor():
vel.y = JUMP_SPEED
elif swipe == 'left' || swipe == 'right':
tween.interpolate_property(self, "translation",
translation, translation+Vector3(-2 if swipe == 'left' else 2,0,0), 0.2,
Tween.TRANS_CUBIC, Tween.EASE_IN_OUT)
tween.start()
swipe = 'swiped'
vel = move_and_slide(vel, Vector3.UP)
func _input(e):
if e is InputEventScreenDrag:
if !swipe:
if e.relative.y < -SWIPE_SPEED:
swipe = 'up'
elif e.relative.x < -SWIPE_SPEED:
swipe = 'left'
elif e.relative.x > SWIPE_SPEED:
swipe = 'right'
elif e is InputEventScreenTouch:
if !e.pressed:
swipe = ''
J'ai décrit chaque ligne, j'espère, avec des scripts tout est plus ou moins clair.Si en russe, alors lorsque nous déplaçons notre doigt sur l'écran, nous enregistrons le sens du mouvement et la vitesse. Si le doigt bouge à la vitesse désirée, on compte le glissement. En fonction de l'axe et de la direction du mouvement, nous avons trois options: HAUT, GAUCHE, DROITE.Nous écrivons la valeur reçue dans une variable, qui est immédiatement captée par l'événement de mise à jour de l'état de l'objet, et effectue les actions nécessaires avec lui, après quoi il marque l'événement comme rempli et attend le suivant.Je n'ai pas pris le moyen le plus simple pour implémenter un balayage, mais il est assez fiable et fonctionne dans la plupart des situations. Bien sûr, cela dépend du genre et du type de jeu.À la suite du travail effectué, nous obtenons un exemple de la facilité avec laquelle il est possible de mettre en œuvre la gestion de balayage en dix minutes.Au total, cela m'a pris environ 30 minutes, cela tient compte de la création de modèles dans Blender.Eh bien, selon la tradition ...Vidéo de développement