DEV Community: Bgie

Een beat-em-up game maken met Godot - health

Bgie — Fri, 16 Jun 2023 19:03:46 +0000

Terug naar deel 7

Onze speler is nog onsterfelijk, maar dat willen we niet. We gaan hem een beperkt aantal levens geven.

In het player.gd script voegen we helemaal vanboven (na de extends CharacterBody2D) toe:

var health_points: int = 3

Wat wil dit zeggen?

var hebben we al gebruikt en betekend: maak een variabele.
health_points is de naam de we hebben gekozen voor de variabele.
: int zegt dat onze variabele altijd een integer is (geheel getal zonder komma). Als we ons vergissen in de code, gaat Godot ons waarschuwen. Dit is een hulpmiddel.
= 3 is de start waarde, onze speler begint met 3 levens.

We gaan deze variabele nu gebruiken in onze take_damage() functie. Die zou er nog zo uit moeten zien:

func take_damage():
    if state == State.READY:
        state = State.HURT
        sprite.play("hurt")

Die code zorgt enkel voor de juiste animatie als de speler geraakt wordt. We willen nu dat een aanval een leven kost.

func take_damage():
    health_points = health_points - 1
    if state == State.READY:
        state = State.HURT
        sprite.play("hurt")

De nieuwe code doet een eenvoudige berekening. De nieuwe health_points (links) wordt gelijk aan de oude health_points min 1.
Dus iedere keer als we in take_damage() komen gaat de speler 1 leven minder krijgen.

We voegen nog een stukje voorlopige code toe, om nu snel te kunnen testen:

func take_damage():
    health_points = health_points - 1
    if health_points == 0:
        self.queue_free()
    if state == State.READY:
        state = State.HURT
        sprite.play("hurt")

Als de health_points zijn verminderd tot nul, laten we de speler verdwijnen met self.queue_free(), zoals bij de vijand. We gaan dadelijk een beter einde maken, maar deze code kunnen we nu al testen.

Het is vaak een goed idee je code in kleine stapjes aan te passen, en telkens te testen of het werkt. Schrijf je honderden regels ineens, zonder testen, dan kom je voor verrassingen te staan wanneer je het uiteindelijk wil testen. Dan is het moeilijker om de fout te vinden, tussen die honderden regels.

Dit is ons resultaat:

Wat we eigenlijk willen, is een death animation zoals bij de vijand. Daarvoor voegen we nog een state toe: DYING.

enum State {READY, ATTACK, HURT, DYING}

Onze take_damage() wordt ook uitgebreid:

    if state == State.DYING:
        return
    health_points = health_points - 1
    if health_points == 0:
        state = State.DYING
        sprite.play("die")
    elif state == State.READY:
        state = State.HURT
        sprite.play("hurt")

Wat veranderd er?

we starten met een if en een return, want als de speler al dood gaat, is een nieuwe take_damage niet meer nodig. return zorgt dat we onmiddellijk uit de functie gaan, de rest van de code wordt overgeslagen.
de tijdelijke self.queue_free() vervangen we. We zetten onze state op DYING en starten de juiste animatie "die"
de laatste if wordt een elif. Enkel als de eerste if niet waar is, gaan we deze tweede elif doen. DYING heeft voorrang op HURT (staat eerst), en als de speler dood gaat doen we nooit een HURT.

Er komt nog 1 regel bij in _on_animated_sprite_2d_animation_finished.
De huidige code dient om na een ATTACK of een HURT terug naar de gewone READY te gaan, zodat we niet eeuwig blijven aanvallen of hurten.

Maar dood gaan is wel redelijk definitief... De nieuwe code:

func _on_animated_sprite_2d_animation_finished():
    if state != State.DYING:
        state = State.READY

Enkel voor states verschillend van DYING zetten we de state terug op READY.

Het resultaat:

... en onze zeer enthousiaste vijand blijft lekker doormeppen!

Wat er nu nog ontbreekt aan ons player health systeem, is een manier om te tonen hoeveel levens de speler nog heeft.

Daarvoor maken we een HUD (heads-up-display). Dit is een vaste laag bovenop alle graphics van de game wereld, die nooit met de camera mee beweegt. We willen linksboven in het scherm met een reeks hartjes tonen hoeveel levens de speler nog heeft.

We maken een nieuwe scene voor onze HUD. Klik met de rechtermuisknop op res:// in het FileSystem paneel en kies New en Scene.

Vervolgens kiezen we als node type CanvasLayer en we geven ook de naam 'HUD' aan onze scene.

We krijgen nu een nieuwe scene, gelijkaardig aan onze andere scenes. Het verschil tussen een CanvasLayer en onze andere scenes, is dat de CanvasLayer NIET beïnvloed wordt door de camera. Dit is nu van geen belang, omdat we de camera (nog) niet verschuiven in onze game. Maar doen we dit later wel, dan willen we dat onze HUD op een vaste plaats in het scherm blijft staan.

Bij onze graphics zitten nog geen hartjes. Maar je kan gemakkelijk png afbeeldingen van het web gebruiken in je game.

Maak eerst een aparte map bij je assets. Je kan met rechtermuisknop klikken op de 'assets' map en via New en Folder een nieuwe map maken die we 'HUD' gaan noemen.

De nieuwe map komt onder je assets te staan:

Dit is het hartje dat we gaan gebruiken:

Afhankelijk van je web browser is dit iets verschillend, maar meestal kan je rechts klikken en is er een save image as optie. Verander de naam naar iets duidelijker zoals 'heart.png'. Je kan de naam ook veranderen vanuit Godot.

Nu gaan we de hartjes toevoegen aan onze scene.
Zorg dat de 'HUD' node is geselecteerd in je scene en klik de grote plus + om een node toe te voegen. We kiezen voor een TextureRect.

We veranderen de naam van onze TextureRect naar 'Hearts', en voegen een Texture toe. We kiezen load en zoeken onze 'hearts.png' in de 'assets/HUD' map.

Dit levert ons 1 hartje op:

Er zijn meerdere manieren om nu meerdere hartjes te krijgen. Het ligt voor de hand om simpelweg meerdere TextureRect nodes te maken. Maar we gaan een truc gebruiken, waarbij we de grafische kaart al het werk laten doen. De grafische kaart kan zonder veel moeite een texture herhalen, dat is iets wat bijvoorbeeld in 3D games voortdurend gebruikt wordt.

We veranderen:

Expand Mode naar Ignore Size. De grafische kaart negeert de vaste afmetingen van het hartje .
Stretch Mode zetten we op Tile. De grafische kaart gaat de afbeelding 'tegelen' (=herhalen).
Custom Minimum Size wordt x=360 en y=90.

Het hartje zelf is 120x90 pixels groot. Omdat we tegelen opzetten en vragen om een gebied van 360x90 op te vullen, gaat de grafische kaart het hartje meermaals tekenen om het gevraagde gebied op te vullen. 360 is 3 x 120, we krijgen 3 hartjes.

Wat we nu nog gaan doen, is de hartjes in de linkerbovenhoek plaatsen, met een kleine marge zodat ze niet helemaal tegen de rand van het scherm plakken.

Verander de Anchor Preset naar Custom. Dan krijg je extra parameters, onder Anchor Points, Anchor Offsets en Grow Direction.

Het systeem van anchors (anker-punten) leggen we later beter uit. Zorg nu gewoon dat de Anchor Offsets voor Left en Top op 25 px staan. Daarmee zorgen we voor een afstand van 25 pixels tussen de hartjes en de linker- en bovenrand van het scherm. Kijk even na of de andere waarden (aangeduid met groen) hetzelfde zijn.

De hartjes gaan lichtjes verspringen wanneer je de offsets intypt, maar verder zien we niet veel. We moeten onze HUD nog toevoegen aan de game scene.

Ga naar de 'game' scene en sleep 'HUD.tscn' beneden naar de root node 'Game'.

Onze hartjes verschijnen, maar staan niet linksboven!

Dit is verwarrend, maar toch komen de hartjes juist als we het spel starten.
Het beeld in de editor toont niet wat de camera ziet, maar wat er op de scene staat. Starten we de game, dan kijken we wel door de camera.

Nu rest er enkel nog wat code, om ook werkelijk het aantal levens van de speler te tonen in de HUD.

In de 'HUD' scene selecteren we de 'HUD' root node en voegen een nieuw script toe. Dit krijgt automatisch de naam 'HUD.gd', wat prima is.

Het script ziet er zo uit:

extends CanvasLayer

@onready var hearts: TextureRect = $Hearts

func set_health(health: int):
    hearts.custom_minimum_size.x = health * 120

Wat doen we hier? De variabele 'hearts' verwijst naar de TextureRect die onze hartjes toont. De functie set_health krijgt in de parameter 'health' mee hoeveel hartjes er getoond moeten worden. We weten dat een hartje 120 pixels breed is, en als we 120 maal 'health' doen, hebben we de breedte voor onze TextureRect om het juiste aantal hartjes te tonen.

Dit moeten we nog verbinden met de player.
Omdat onze player en onze HUD twee aparte scenes zijn, die niets van mekaar afweten, gaan we de verbinding leggen in onze game scene.

We voegen ook een script toe aan de root node 'Game' van onze game scene.

De eenvoudigste code is als volgt:

extends Node2D

@onready var player: CharacterBody2D = $Arena/Player
@onready var hud: CanvasLayer = $HUD

func _process(_delta):
    hud.set_health(player.health_points)

We maken de variabelen 'player' en 'hud' die de juiste node opzoeken en opslaan (via het $ symbool). De functie _process(_delta) wordt bij elke frame opgeroepen. Hier vragen we player.health_points op en geven dit door aan onze set_health functie van de HUD.

Dit kan efficiënter als we player een signaal laten uitsturen enkel wanneer health_points wijzigt, maar voorlopig is dit goed genoeg.

Met onze HUD kunnen we nog meer doen. In het volgende deel maken we een "Game Over" scherm en de mogelijkheid om een nieuw spel te starten.

Een beat-em-up game maken met Godot - hurtboxes en hitboxes

Bgie — Fri, 02 Jun 2023 21:03:33 +0000

Terug naar deel 6

Het vecht-systeem is gebaseerd op 'hitboxes' en 'hurtboxes'.

Het slachtoffer van een aanval heeft een hitbox. Het wapen van de aanvaller heeft een hurtbox. Als de hurtbox van de aanvaller de hitbox van het slachtoffer raakt, krijgt het slachtoffer 'damage'.

Beiden gaan we maken met CollisionShape2D objecten, waar we ook onze botsingen mee maakten.

We hadden al een CollisionShape2D op de voeten geplaatst van onze personages. Dit kunnen we ook gebruiken voor als hitbox. Om dit duidelijk te maken, veranderen we naam van deze nodes, zowel voor de 'Player' als voor de 'Minotaur':

Vervolgens gaan we de hurtbox voor het wapen maken. Bij de speler voegen we 2 nodes toe, een Area2D en daaronder een CollisionShape2D:

Om de hurtbox op de juiste plaats te kunnen zetten, gaan we tijdelijk onze AnimatedSprite2D verzetten naar de juiste frame (5) voor de "attack" animatie. Zo zien we waar het wapen neerkomt.

Zoals we al eerder deden, moeten we nu een Shape toevoegen aan onze CollisionShape2D. Hiervoor gebruiken we een CapsuleShape2D.

We zetten enkele waardes van onze CapsuleShape2D juist: de Radius wordt 130 px, de Height wordt 400 px en onze Position krijgt een x van 300. Het is ook mogelijk de kleur (Debug Color) aan te passen, maar dit zie je niet in de game zelf, enkel in de editor tijdens het ontwerpen.

Onze hurtbox noemt nog Area2D, de standaard naam. Het is duidelijker als we deze van naam te veranderen:

Onze code hangen we aan het signaal body_entered(body: Node2D) dat hoort bij onze hurtbox. (In de screenshot heet de hurtbox nog Area2D)

De functie die we nu krijgen van Godot heeft een parameter body. Dit is een variabele waarin het object zit waar we mee botsen. Allerlei objecten kunnen botsen, en niet elk object kunnen we aanvallen.

Onze vijand, die kan aangevallen worden, gaan we dadelijk een "take_damage" functie geven. In onze _on_hurt_box_body_entered van de speler kunnen we aan Godot vragen of de body waar we mee botsen zo een functie "take_damage" heeft.
Indien ja, dan roepen we die aan.

We passen onze _on_hurt_box_body_entered functie aan:

func _on_hurt_box_body_entered(body):
    if body.has_method("take_damage"):
        body.take_damage()

Het "take_damage" gedeelte komt in het script van de vijand. We voegen daar deze nieuwe functie toe. self.queue_free() is de instructie om de vijand te laten verdwijnen. We zorgen straks voor een 'sterf' animatie.

In het script van de vijand:

func take_damage():
    self.queue_free()

Als we dit testen, merken we dat er nog een probleem is. De vijand verdwijnt wel degelijk, maar onze speler moet niet eens aanvallen! Om dit correct te doen, moeten we de hurtbox enkel actief maken wanneer het wapen neerkomt.

We zorgen dat onze hurtbox in het begin UIT staat, en geen botsingen gaat detecteren. We zetten Monitoring en Monitorable allebei uit.
We zetten ook Layer 1 uit bij het collision gedeelte. Dit zorgt ervoor dat onze hurbox niet meetelt als 'hard' object voor botsingen. Andere objecten in laag 1 kunnen gewoon door onze hurtbox heen bewegen. Enkel Mask staat op, wat wil zeggen dat onze hurbox wel gaat kijken naar andere objecten.

Nu willen we onze hurtbox AAN zetten wanneer het wapen neerkomt. Als we gaan kijken in onze AnimatedSprite2D bij de "attack" animatie, zien we alle frames en hun nummers. In frame 4 tot 7 komt het wapen neer. We verbinden het signaal frame_changed() aan ons script:

Vanboven in de code van de speler maken we een tweede @onready variabele om aan onze hurtbox te kunnen:

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D
@onready var hurtbox: Area2D = $HurtBox

De code voor onze _on_animated_sprite_2d_frame_changed bestaat uit enkele eenvoudige if instructies. Als de "attack" animatie aan frame 4 komt, zetten we monitoring van de hurtbox aan. Bij frame 7 terug uit.

func _on_animated_sprite_2d_frame_changed():
    if sprite.animation == "attack":
        if sprite.frame == 4:
            hurtbox.monitoring = true
        elif sprite.frame == 7:
            hurtbox.monitoring = false

De frame_changed() functie wordt altijd opgeroepen, zelfs als de grafische kaart te traag is om het beeld feitelijk te tonen (lage FPS).

We hebben nu dit:

De vijand verdwijnt gewoon, terwijl we een sterf animatie voor onze vijand hebben. Die willen we natuurlijk gebruiken!

Het is eenvoudig om dit aan onze state machine toe te voegen. In het script van de vijand voegen we een extra state toe, DYING.

enum State {READY, ATTACK, DYING}

In de take_damage() functie gaan we niet onmiddellijk de vijand laten verdwijnen, maar gaan we naar onze nieuwe DYING state switchen en de juiste animatie starten.

func take_damage():
    if state != State.DYING:
        sprite.play("die")
        state = State.DYING

Dit kan je testen, het werkt, maar na de dramatische val komt onze vijand gewoon terug recht. Dat komt door onze animation_finished code, die we hebben geschreven voor het aanvallen.

We passen de _on_animated_sprite_2d_animation_finished functie dus ook aan:

func _on_animated_sprite_2d_animation_finished():
    if state == State.DYING:
        self.queue_free()
    else:
        state = State.READY

Nu verdwijnt onze vijand na het omvallen.

Het is pas helemaal af met een fade-out animatie. Een manier om een eenvoudige animatie te starten vanuit code is met een tween. We maken een tween, en voegen een aantal animatie stappen toe, die de tween dan erna gaat uitvoeren. De animatie is als volgt: eerst 3 seconden wachten, dan de kleur van onze sprite geleidelijk over laten gaan naar transparant, gedurende 1 seconde. Dan pas volgt de queue_free() waarmee onze vijand verdwijnt. De animatie wordt samengesteld in onze code, maar start pas nadat onze functie _on_animated_sprite_2d_animation_finished afgelopen is.

func _on_animated_sprite_2d_animation_finished():
    if state == State.DYING:
        var tween = create_tween()
        tween.tween_interval(3)
        tween.tween_property(sprite, "modulate", Color.TRANSPARENT, 1)
        tween.tween_callback(self.queue_free)
    else:
        state = State.READY

Het is niet erg fair dat onze vijand zich niet kan verdedigen. We gaan dezelfde stappen herhalen voor de vijand, zodat de vijand onze speler ook pijn kan doen.

In het Scene paneel van de minotaurus voegen we ook een Area2D toe met daaronder een CollisionShape2D. De Area2D geven we een ander naam: HurtBox.
De CollisionShape2D krijgt een CapsuleShape2D als vorm, met een Radius van 150 px, een Height van 500 px en een Position met x = 400 px. De Debug Color kleur mag je ook aanpassen als je wil.

We verbinden ook het body_entered(body: Node2D) signaal.

We kunnen hier dezelfde code gebruiken als voor onze speler:

func _on_hurt_box_body_entered(body):
    if body.has_method("take_damage"):
        body.take_damage()

We moeten straks gewoon zorgen dat onze speler ook een "take_damage" functie heeft.

Eerst gaan we zorgen dat de onze hurtbox enkel actief is wanneer de knuppel neerkomt.

De hurtbox van onze minotaurus passen we aan: Monitoring en Monitorable moeten UIT, en Layer 1 moet ook UIT.

Dan verbinden we frame_changed() van de AnimatedSprite2D met ons script.

Net als bij de speler maken we een nieuwe @onready variabele om aan de hurtbox te kunnen vanuit de Enemy.gd code:

@onready var hurtbox: Area2D = $HurtBox

De functie voor frame_changed is identiek aan die van de speler, enkel de frame nummers zijn verschillend:

func _on_animated_sprite_2d_frame_changed():
    if sprite.animation == "attack":
        if sprite.frame == 8:
            hurtbox.monitoring = true
        elif sprite.frame == 11:
            hurtbox.monitoring = false

Om dit stuk al te testen, maken we tijdelijk een "take_damage" functie in het Player.gd script:

func take_damage():
    self.queue_free()

Als we dit testen, dan lijkt het niet te werken. Er is een fout in de code geslopen, blijkbaar werkt de hurtbox alleen maar aan de rechterzijde van de vijand!

Dit probleem had ik zelf niet voorzien, en ik wil de vorige screenshots niet opnieuw maken :(

De oplossing is gelukkig niet moeilijk. Het probleem zit in het spiegelen van de personages als ze naar links lopen, met de code sprite.scale.x = -1. Daar spiegelen we enkel de AnimatedSprite2D. Maar de hurtbox blijft natuurlijk op dezelfde plaats staan, aan de rechterzijde van de sprite.

We lossen dit op door de hurtbox van onze minotaurus te verslepen met de muis, en een kind te maken van de AnimatedSprite2D. Als we dan spiegelen, worden de kind nodes ook mee gespiegeld. De hurtbox komt dan ook aan de linkerzijde te liggen.

Er is een kleine wijziging nodig in onze Enemy.gd code, omdat we de hurtbox gebruiken in onze code. De plaats waar de hurtbox staat is nu anders, hij is een kind geworden van de AnimatedSprite2D. De regel:

@onready var hurtbox: Area2D = $HurtBox

... wordt nu ...

@onready var hurtbox: Area2D = $AnimatedSprite2D/HurtBox

De bug zit ook in onze player code. Ook daar moeten we de hurtbox node verslepen in de Scene en de code aanpassen.

Er schuilt echter nog een subtiele bug in ons spel. Slaat de speler naar links met zijn staf, dan verdwijnt hij zelf!

Dit is een goede gelegenheid om een debug optie van Godot te demonstreren. In het debug menu kan je Visible Collision Shapes opzetten.

Dan krijg je de botsingen te zien in de game, en dan zien we dit:

Omdat de tekening van de engel niet helemaal in het midden staat, hebben we een probleem als we spiegelen. De hurtbox van de speler raakt zijn eigen hitbox!

Er is een manier om dit op te lossen door verschillende lagen te gebruiken voor de botsingen, maar daar gaan we nu niet op ingaan.

De eenvoudigste manier is, om in de CollisionShape2D van de speler de CapsuleShape2D wat smaller te maken. We veranderen de Radius naar 120 px.

Alles lijkt nu te werken!

In de plaats van een instant-death voor onze speler, willen we misschien liever meerdere levens. Krijgt de speler een mep, dan spelen we de "hurt" animatie in plaats van te verdwijnen.

We voegen een nieuwe state toe in Player.gd:

enum State {READY, ATTACK, HURT}

Onze take_damage maken we minder fataal:

func take_damage():
    if state == State.READY:
        state = State.HURT
        sprite.play("hurt")

Een andere kleine wijziging is ook nodig: de vijand mept veel te snel, en de speler krijgt geen kans om te ontsnappen.

Open de 2D view van de minotaurus, en open de SpriteFrames van de AnimatedSprite2D. In de "attack" animatie gaan we de laatste frame (11) langer laten duren. We zetten de Frame Duration op 20.

Hetzelfde kunnen we doen voor de speler, maar hier gebruiken we 10 frames als vertraging. De staf van de speler is wat sneller dan de knuppel van de minotaurus.

Dankzij de vertraging kan de speler nog weglopen wanneer de minotaurus begint te meppen, maar hij krijgt toch een stevig pak rammel!

In de volgende delen gaan we nog toevoegen:

nieuwe vijanden die spawnen
een beperkt aantal levens voor de speler
game over en een high-score systeem

In het volgende deel implementeren we een basis 'health' systeem voor onze player.

Een beat-em-up game maken met Godot - meppen!

Bgie — Sat, 06 May 2023 10:05:19 +0000

Terug naar deel 5

We hadden al een attack animatie gemaakt voor onze held, die gaan we nu gebruiken. Ons script voor de 'Player' gaan we uitbreiden.

Om aanvallen mogelijk te maken, gaan we een concept gebruiken dat vaak terugkomt in games: een 'state machine'.

Een 'state' is een toestand waarin ons personage zich bevindt. Er bestaan meerdere states, maar er is er maar eentje actief. Afhankelijk van de state die actief is, wordt er andere code uitgevoerd.

Dit wordt duidelijker met een voorbeeld: we gaan een ATTACK state toevoegen, en als de speler in de ATTACK state zit, mag hij niet meer bewegen tot de aanval gedaan is. De gewone state noemen we READY, dan mag de speler wel rondlopen. Later gaan we ook de state DEAD gebruiken.

In het eerste stuk van ons 'Player' script voegen we volgende regels toe:

enum State {READY, ATTACK, DEAD}
var state: State = State.READY

De enum is een opsomming (enumeratie) van states die we willen gebruiken. In de variabele state slaan we de huidige state van onze speler op.

Het gebruiken van states kan heel eenvoudig, met gewone ifs. Vaak wordt in tutorials complexe code met klassen en polymorfisme gebruikt, maar zo moeilijk moet het daarom niet zijn.

Onze bestaande code om de speler te bewegen komt nu binnen een if/elif blok te zitten:

func _physics_process(_delta):
    if state == State.ATTACK:
        pass
    elif state == State.READY:
        velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
        velocity.y = Input.get_axis("ui_up", "ui_down") * SPEED
        [...]

Dit doet natuurlijk nog niets, want state == State.READY gaat gewoon altijd waar zijn. We moeten nog code toevoegen om een overgang tussen states te maken.

We doen dat via keyboard input, en zetten van onze state variabele op een andere waarde.

De uiteindelijke code in _physics_process ziet er nu zo uit:

func _physics_process(_delta):
    if state == State.ATTACK:
        pass
    elif state == State.READY:
        if Input.is_action_just_pressed("ui_accept"):
            state = State.ATTACK
            sprite.play("attack")
        else:
            velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
            velocity.y = Input.get_axis("ui_up", "ui_down") * SPEED

            if velocity.x < 0:
                sprite.scale.x = -1
            elif velocity.x > 0:
                sprite.scale.x = 1

            if velocity:
                move_and_slide()
                sprite.play("walk")
            else:
                sprite.play("idle")

De input "ui_accept" is standaard gekoppeld aan zowel de SPACE als de ENTER toets.
Enkel als onze speler in de READY state zit, gaan we kijken of er een aanval gestart moet worden. Daar zetten we de state op State.ATTACK. Alle volgende frames wanneer _physics_process wordt opgeroepen, zal in de bovenste 'if' enkel het stukje code bij de ATTACK state uitgevoerd worden. Alle code om rond te lopen wordt overgeslagen. De speler moet eerst zijn attack afwerken!

Als we deze code uitvoeren merken we dat er nog iets ontbreekt: als je 1 maal een attack start, blijft de speler meppen. Er is ook nog code nodig om de aanval te stoppen.

Daarvoor gebruiken we een signaal dat van de AnimatedSprite2D komt: animation_finished(). We gaan code hangen aan dit signaal. Open het Node paneel en Klik rechts op animation_finished(). Kies daar Connect....

In de volgende dialoog zorg je dat we het Player script gebruiken (dit is de standaard optie). De voorgestelde naam on_animated_sprite_blabla voor de functie (receiver method) is prima. Klik op Connect.

We krijgen een nieuwe functie met pass (niks doen) als voorlopige inhoud.

func _on_animated_sprite_2d_animation_finished():
    pass # Replace with function body.

Dit veranderen we naar:

func _on_animated_sprite_2d_animation_finished():
    state = State.READY

Dit kunnen we in-game testen. Spatie-balk laat de speler 1 maal meppen. Blijven indrukken = blijven meppen. Dit kan later verbeterd worden met bijvoorbeeld een cooldown timer.

Voor onze vijand doen we ongeveer hetzelfde. We maken ook een eenvoudige state machine met een state variabele:

enum State {READY, ATTACK}
var state: State = State.READY

De hele code in _physics_process komt een niveau dieper te zitten in een if/elif blok:

func _physics_process(_delta):
    if state == State.ATTACK:
        pass
    elif state == State.READY:
        if target != null:
            var delta: Vector2 = (target.position - self.position)
            var direction = delta.normalized()
            var distance = delta.length()
            if distance > ATTACK_DISTANCE_MAX:
                velocity = direction * SPEED
            elif distance < ATTACK_DISTANCE_MIN:
                velocity = direction * -SPEED
            else:
                velocity = Vector2()

            if delta.x < 0:
                sprite.scale.x = -abs(sprite.scale.x)
            elif delta.x > 0:
                sprite.scale.x = abs(sprite.scale.x)

        if velocity:
            sprite.play("walk")
        else:
            sprite.play("idle")

        move_and_slide()

Ook hier moeten zorgen dat onze vijand effectief wisselt van state om een aanval te starten. Maar we hebben al een if/else waar we dit kunnen inschuiven! Als de vijand net ver genoeg staat, dus tussen ATTACK_DISTANCE_MAX en ATTACK_DISTANCE_MIN staat, dan starten we een aanval.

            if distance > ATTACK_DISTANCE_MAX:
                velocity = direction * SPEED
            elif distance < ATTACK_DISTANCE_MIN:
                velocity = direction * -SPEED
            else:
                velocity = Vector2()
                state = State.ATTACK

Ook niet vergeten om onze animatie correct aan te passen. Waar we normaal enkel naar velocity kijken om te kiezen tussen "walk" of "idle", gaan we nu eerst kijken of we net naar de ATTACK state zijn gegaan. In dat geval starten we de attack animatie. De regel if velocity wordt nu een elif velocity.

        if state == State.ATTACK:
            sprite.play("attack")
        elif velocity:
            sprite.play("walk")
        else:
            sprite.play("idle")

Net als bij de speler gaan we het animation_finished() signaal gebruiken om de aanval af te sluiten. We verbinden het signaal zoals we eerder deden:

Onze nieuwe functie die we kregen van Godot passen we aan, we veranderen de state terug naar READY als de aanval klaar is:

func _on_animated_sprite_2d_animation_finished():
    state = State.READY

Het resultaat:

Onze personages zijn nog 'onsterfelijk'... in het volgende deel zorgen we dat de speler en vijanden geraakt kunnen worden en sterven.

Een beat-em-up game maken met Godot - bewegende vijand

Bgie — Fri, 05 May 2023 17:43:41 +0000

Terug naar deel 4

Wat hebben we nu al gemaakt? Een wereld met een speler die kan rondlopen, en een vijand, die gewoon wat staat te staan... nog niet bepaald een leuke game...

Wat willen we: vijanden die net buiten beeld vertrekken en de speler komen aanvallen. We gaan ons werk in 3 delen splitsen:

vijanden moeten naar de speler toe lopen
vijanden en de speler moeten kunnen vechten en doodgaan.
net buiten beeld moeten telkens nieuwe vijanden 'spawnen'

We starten met het lopen van de vijand. Plaats eerst de speler en de vijand op een goede startpositie in de wereld. De speler start links-midden, en de vijand uiterst rechts net buiten beeld:

Nu gaan we code schrijven om onze vijand te laten bewegen. Open de minotaurus scene en het script voor de vijand.

Net als bij de speler gaan we een 'constante' maken voor de snelheid waarmee dit personage beweegt. We zetten hem op 250, langzamer dan de speler, zodat de speler nog kan weglopen. Deze regel komt in het bovenste deel van het script:

const SPEED = 250.0

De beweging van onze vijand hangt niet af van het toetsenbord, zoals bij onze speler, maar van de positie van die speler tegenover onze vijand.

De code om te bewegen komt bij in onze bestaande _physics_process functie die we al hadden.

Eerste stap is het opzoeken van de node van onze player. Dit steken we in een nieuwe variabele 'target', het doelwit van onze minotaurus.

func _physics_process(_delta):
    var target = self.get_parent().get_node("Player")

    sprite.play("idle")

Hoe werkt dit? We hebben in onze 'game' scene ervoor gezorgd dat zowel de 'Player' als de 'Minotaur' kinderen zijn van de 'Arena' node.

In bovenstaande code starten we met self, de Minotaurus node (waar het script aanhangt). get_parent geeft dan de 'Arena' node erboven. Doen we dan get_node("Player") om tussen de child nodes van 'Arena' te zoeken naar een node met de naam 'Player'. Dat is degene die we willen hebben, en die slaan we op in onze nieuwe variabele var target.

Volgende stap is controleren of we wel een tegenstander hebben gevonden.

func _physics_process(_delta):
    var target = self.get_parent().get_node("Player")
    if target != null:
        # movement code 

    sprite.play("idle")

Enkel als de node 'Player' gevonden is (misschien is de speler al dood?) dan gaan we onze minotaurus laten bewegen. null is een speciale waarde die 'niets' betekend. Enkel als onze target NIET null is, gaan we verder.

Nu volgt een stukje wiskunde, om de beweging van onze minotaurus te berekenen.

Denk je ooit tijdens de les wiskunde: waarom moet ik dit allemaal kennen? Wel, computergames gebruiken een hoop wiskunde! En schrijf je uiteindelijk een succesvolle game? Dan heb je ook wiskunde nodig om je hopen geld te kunnen tellen.

De code is:

func _physics_process(_delta):
    var target = self.get_parent().get_node("Player")
    if target != null:
        var delta = (target.position - self.position)
        var direction = delta.normalized()
        velocity = direction * SPEED

    sprite.play("idle")

Als je nog nooit van vectoren of coördinaten hebt gehoord, geen probleem, hier in het kort wat er gebeurt:

De posities van de 2 personages kan je in getallen uitdrukken.

De horizontale as (links-rechts) noemen we x. De speler staat op x=4000.
De verticale as (boven-onder) noemen we y. De speler staat op y=500.
Samen noemen we dat de coördinaten van de speler (x,y). De speler staat op (4000, 500), de minotaurus staat op (5000, 1000).

We kunnen rekenen met coördinaten, zoals we met eenvoudige getallen doen.

Het verschil tussen de positie van de speler (target) en de minotaurus (self) geeft ons de blauwe pijl op de tekening.
In code uitgedrukt: target.position - self.position.
In ons voorbeeld is de uitkomst (4000,500) - (5000, 1000) = (-1000, -500).

We slaan dit op in variabele delta.
Delta geeft ons de richting en afstand naar de target.

We willen enkel de richting gebruiken, en dan met een vaste snelheid een stukje bewegen in die richting. Zonder te veel details te geven, maar normalized doet net dat, en geeft als uitkomst de groene pijl.

De groene pijl is een pijl met lengte 1 met dezelfde richting als de blauwe pijl. Dit slaan we op in var direction.

De laatste regel velocity = direction * SPEED gebruikt de groene pijl (direction) en onze constante snelheid (SPEED) om de snelheid van bewegen voor onze minotaurus te bepalen. Dit steken we in velocity, een bestaande variabele die bij onze CharacterBody2D hoort.

Nu volgt enkel nog het bewegen zelf, met de juiste animatie.

Die code is gelijkaardig aan de code van de speler. Als onze minotaurus snelheid heeft (velocity is niet nul) dan spelen we de 'walk' animatie. Anders spelen we 'idle'. De move_and_slide() doet het feitelijke bewegen op basis van de velocity, rekening houdend met botsingen.

Alles te samen ziet onze code er nu zo uit:

extends CharacterBody2D

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

const SPEED = 250.0

func _physics_process(_delta):
    var target = self.get_parent().get_node("Player")
    if target != null:
        var delta = (target.position - self.position)
        var direction = delta.normalized()
        velocity = direction * SPEED

    if velocity:
        sprite.play("walk")
    else:
        sprite.play("idle")

    move_and_slide()

Dit kunnen we testen met Run Project of F5. Daar komt ie!

Merk op dat onze vijand nogal 'plakkerig' is... hij stopt nooit en loopt tot tegen de speler, en blijft maar lopen.

Hij loopt ook achteruit, maar dat kennen we al en kunnen we oplossen zoals bij de speler. Er is een klein verschil, we hebben de scale van onze minotaurus op 1.5 gezet omdat hij wat klein was.

Als we dezelfde code gebruiken als bij de speler:

    if velocity.x < 0:
        sprite.scale.x = -1
    elif velocity.x > 0:
        sprite.scale.x = 1

... dan gaat onze scale terug verspringen naar 1 of -1, en is onze minotaurus terug klein.

Met de wiskundige functie abs kunnen we dit oplossen. abs geeft de absolute waarde van een getal, wat wil zeggen dat een min-teken wordt weggelaten als dit er is, elk getal wordt positief gemaakt.

In de volgende code behouden we het getal dat in sprite.scale.x zit, en veranderen we enkel het teken van plus naar min of omgekeerd, zodat de scale van de minotaurus van 1.5 behouden blijft.

    if velocity.x < 0:
        sprite.scale.x = -abs(sprite.scale.x)
    elif velocity.x > 0:
        sprite.scale.x = abs(sprite.scale.x)

Het andere probleem, dat onze minotaurus eeuwig blijft lopen, kunnen we oplossen met een paar extra ifs.

Als de minotaurus ver weg is, willen we dat hij naar de speler toeloopt. Is hij te dichtbij, dan moet hij naar achteren. Zit hij op de ideale afstand, dan mag hij blijven staan, dan gaat hij aanvallen. De afstanden steken we in een paar constanten:

const ATTACK_DISTANCE_MAX = 520.0
const ATTACK_DISTANCE_MIN = 480.0

De logica zelf komt bij in onze _physics_process. We berekenen de afstand tussen onze minotaurus en de speler uit de variabele delta die we al hadden. Met die afstand kunnen we ifs schrijven.

        var distance = delta.length()
        if distance > ATTACK_DISTANCE_MAX:
            velocity = direction * SPEED
        elif distance < ATTACK_DISTANCE_MIN:
            velocity = direction * -SPEED
        else:
            velocity = Vector2()

Het uiteindelijke script:

extends CharacterBody2D

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

const SPEED = 250.0
const ATTACK_DISTANCE_MAX = 520.0
const ATTACK_DISTANCE_MIN = 480.0

var target: Node2D

func _ready():
    target = self.get_parent().get_node("Player")

func _physics_process(_delta):
    if target != null:
        var delta: Vector2 = (target.position - self.position)
        var direction = delta.normalized()
        var distance = delta.length()
        if distance > ATTACK_DISTANCE_MAX:
            velocity = direction * SPEED
        elif distance < ATTACK_DISTANCE_MIN:
            velocity = direction * -SPEED
        else:
            velocity = Vector2()

        if delta.x < 0:
            sprite.scale.x = -abs(sprite.scale.x)
        elif delta.x > 0:
            sprite.scale.x = abs(sprite.scale.x)

    if velocity:
        sprite.play("walk")
    else:
        sprite.play("idle")

    move_and_slide()

In het volgende deel starten we met het gevecht systeem.

Een beat-em-up game maken met Godot - een vijand

Bgie — Tue, 02 May 2023 16:45:08 +0000

Terug naar deel 3

We gaan een vijand toevoegen. De basis onderdelen zijn:

de animatie frames
een collision shape
en een enemy script

Hiervoor maken we eerst een nieuwe scene. In het paneel linksonder, klik je met de rechtermuisknop op res://. Vervolgens kies je new en dan scene.

In de Create New Scene dialoog klikken we op de Pick Root Node Type knop.

Dan kunnen we in de Recent lijst opnieuw CharacterBody2D kiezen. Deze gebruikten we eerder ook voor de speler. Bevestig met de pick knop.

Terug in de eerste dialog, typen we nu een naam voor onze vijand: 'Minotaur'. We bevestigen met ok en onze nieuwe scene wordt gemaakt.

Net zoals bij onze speler voegen we 2 child nodes toe aan onze minotaurus: AnimatedSprite2D en CollisionShape2D.

Een shape instellen voor de collision shape is net hetzelfde als bij de speler. De vorm is ook een gedraaide CapsuleShape 2D maar wat groter: radius = 50, height = 350 en rotation = 90.

Onze AnimatedSprite2D heeft SpriteFrames nodig, die voegen we toe:

Klikken we nu nogmaal op deze nieuwe SpriteFrames dan opent het paneel waar we de animaties kunnen samenstellen.

De minotaurus animaties zijn dezelfde als die van de speler: attack, die, hurt, idle en walk. Deze voegen we toe met de Add Animation knop, en we geven ze de juiste naam. De default animatie mag weg.

Voor elke animatie moeten we nu de juiste beelden toevoegen met de Add frames from file knop. De afbeeldingen staan in submappen van de map 'minotaur' onder onze 'assets'.
Alle animaties spelen aan 30 fps. Enkel de idle en walk animatie hebben looping AAN staan, bij de rest staat dit UIT.

Onze AnimatedSprite2D staat nog te laag ten opzichte van onze CollisionShape2D, de voeten van het monster moeten in de blauwe ovaal staan. We passen voor onze AnimatedSprite2D de position aan naar y = -200.

Onze vijand tot leven brengen doen we met een script. Zorg dat de root node 'Minotaur' geselecteerd is en klik op de Attach Script knop.

In de volgende dialoog gaan we een andere naam kiezen voor ons script: we noemen het script 'res://Enemy.gd' omdat we hetzelfde script willen gebruiken voor meerdere soorten vijanden. Bevestig door op Create te klikken.

Het script voor de vijand gaan we geleidelijk opbouwen. We starten met het minimum: de vijand staat gewoon stil.
Verwijder alle voorbeeldcode en gebruik dit:

extends CharacterBody2D

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

func _physics_process(_delta):
    sprite.play("idle")

Om te kunnen testen gaan we onze vijand in de wereld plaatsen. Sla eerst de huidige scene op met Ctrl+S of kies in het hoofdmenu linksboven Scene - Save.

Dan keren we terug naar de 2D view en selecteren we onze 'game' scene. We slepen onze 'Minotaur.tscn' vanuit het FileSystem naar de 'Arena' node in onze scene. Daarna kan je de speler en de vijand verslepen in de wereld zelf, zodat ze niet vlak bij mekaar staan.

Het valt misschien dadelijk op dat ons monstertje niet heel indrukwekkend is... We gaan hem eerst wat groter maken!
Dit is zo gebeurd: we openen terug de 'minotaur' scene, selecteren de AnimatedSprite2D en zetten de scale op 1.5
Nu staan onze voeten niet meer op de juiste plaats, daarom passen we position terug aan zodat y = -300

Nu dit gebeurd is, kunnen we testen! Start de game met de Run Project knop of F5.

Als we naar onze vijand toelopen, merken we dat er nog een probleem is. Het overlappen van de graphics klopt nog niet, onze minotaurus staat altijd vanboven, ook al loopt de speler 'voor' hem.

Als game engine heeft Godot hier natuurlijk een oplossing voor. Onze 'Arena' node heeft bij zijn properties een optie Y Sort Enabled die we eenvoudig aan kunnen zetten.
Staat dit AAN, dan gaat Godot bij het tekenen van de child nodes van 'Arena' kijken naar de hoogte (y positie) en de nodes sorteren zodat de hoogste nodes 'vanonder' komen te liggen.

Dit zit er al beter uit:

In het volgende deel schrijven we een basis AI voor onze vijand: deel 5

Een beat-em-up game maken met Godot - botsingen

Bgie — Sun, 30 Apr 2023 11:09:56 +0000

Terug naar deel 2

In deel 3 van deze reeks zorgen we dat onze speler binnen onze wereld blijft, met het 'collision' systeem van Godot. Dit systeem is ook nodig voor bijvoorbeeld combat en interactie met objecten.

Godot heeft zoals vele game engines een fysica systeem, waarmee we botsingen (collisions) van objecten kunnen simuleren.
De afmetingen van een object staan los van de graphics (tekeningen) op het scherm. Objecten die kunnen botsen zijn meestal opgebouwd uit eenvoudige vormen, zoals rechthoeken, cirkels of lijnen.

Willen we dat onze speler 'binnen' de wereld blijft, dan moeten we 2 zaken toevoegen:

de grenzen van de wereld, waar we ook collision objects voor gaan gebruiken,
en een collision object voor de speler zelf.

We starten met onze speler. Zorg dat de 2D view open staat, en de 'player' scene actief is. Links moet de node die 'CollisionShape2D' heet, geselecteerd zijn.
Dan kiezen we rechts bij shape, een CapsuleShape2D.

De grootte en richting van de CapsuleShape2D kan je met de muis aanpassen, via de kleine handvaten, maar in ons geval doen we het met het toetsenbord en typen we dadelijk de juiste waardes voor radius = 50, height = 300 en rotation = 90:

Om later geen problemen te hebben met sprites die niet op de juiste manier voor of achter mekaar liggen, zorgen we dat de CapsuleShape2D op position x = 0 px en y = 0 px blijft staan.

We gaan de AnimatedSprite2D verplaatsen, zodat de voeten van het personage in de CapsuleShape2D staan. Selecteer de AnimatedSprite2D en verander zijn positie naar x = 10 px en y = -300 px.

Doordat we enkel de voeten gebruiken voor botsingen, kan ons personage voor en achter andere personages lopen. Dit ziet er beter uit. Als we het hele lichaam gebruiken voor botsingen, kan dit niet. De collision shapes kunnen niet overlappen, ze botsen. De sprites kunnen dat wel. Hier zie je het verschil:

Nu gaan we verder met de wereld. Zorg dat de 2D view open staat, en de 'game' scene actief is. Links moet je node die we 'Arena' hebben genoemd, geselecteerd zijn. Deze node is een StaticBody2D, wat wil zeggen dat het een object is dat meedoet aan botsingen, maar dat statisch blijft (niet beweegt). Klik op de + (plus) knop om een child node toe te voegen.

In de Create New Node dialoog voegen we een CollisionShape2D toe.

Voor de boven- en ondergrens van de wereld gebruiken we een simpele lijn. Alles aan 1 kant van de lijn telt als botsing, de andere kant is wandelbaar.

Selecteer de nieuwe CollisionShape2D en maak voor de Shape een nieuwe WorldBoundaryShape2D.

We stellen in welke kant van de lijn wandelbaar is door bij Normal onze y = 1 te maken. (Naar beneden). De lijn zelf zetten we vanboven aan de rand van de bomen door position y = -300 te maken:

Dit kunnen we nu best eens testen. Start het project met de Run Project knop of F5.

De ondergrens van de wereld maken we op dezelfde manier. Selecteer opnieuw de Arena node en voeg een nieuwe CollisionShape2D toe. Deze geven we ook een WorldBoundaryShape2D als vorm.
De normal (richting) staat standaard op x = 0 en y = -1. Dit is goed, dit is naar boven. We veranderen wel de position naar y = 1080.

De linker- en rechtergrens zetten we iets buiten beeld. Dan kunnen straks de vijanden net buiten beeld spawnen.
Maak nog twee maal onder de Arena node een CollisionShape2D, met telkens een WorldBoundaryShape2D

De linkergrens heeft normal x = 1 en y = 0. De position x = -2300 px.
De rechtergrens heeft normal x = -1 en y = 0. De position x = 2300 px.

Als dit klaar is kan je opnieuw testen met Run Project of F5.

In het volgende deel (deel 4) gaan we een vijand toevoegen.

Een beat-em-up game maken met Godot - de speler

Bgie — Sat, 08 Apr 2023 08:55:13 +0000

Terug naar deel 1

In deel 2 van deze reeks voegen we onze speler toe.

Maak een nieuwe scene.

De node die we aanmaken moet van het type CharacterBody2D zijn. Dit is een soort node die wel meedoet met fysica simulatie (vallen en botsen) maar waar we volledige controle over hebben.
Als naam van de scene gebruiken we gewoon 'Player' (dit is vrij te kiezen).

We krijgen nu een extra tabblad voor deze nieuwe 'Player' scene. Via de knoppen hieronder kan je wisselen tussen scenes die je open hebt.

We voegen 2 nodes toe aan onze player:

een AnimatedSprite2D voor de graphics,
en een CollisionShape2D om botsingen te kunnen detecteren.

Om de graphics van de AnimatedSprite2D te kiezen, moeten we eerst zorgen dat ie links geselecteerd is. Dan kunnen we rechts bij Sprite Frames via het uitklap menu een nieuwe SpriteFrames toevoegen.

De nieuwe SpriteFrames is nog leeg. Klik er op. Midden-beneden opent nu de editor voor de SpriteFrames in een paneel.

De Godot ontwikkelomgeving zit vol met panelen en tabbladen... Hieronder zie je de knop die hoort bij het SpriteFrames paneel, waaraan je ziet dat dit paneel open staat.

We gaan onze animaties toevoegen: in het SpriteFrames paneel heb je onder 'Animations' wat knoppen en een lijstje met animaties die in de SpriteFrames zitten.
Met de Add Animation knop voegen we de volgende animaties toe: attack, die, hurt, idle en walk (default mag weg).
De naam veranderen van een animatie kan door 2 keer (langzaam) te klikken met de linkermuisknop.

De volgende knoppen gaan we gebruiken om alle animaties correct in te stellen. Van links naar rechts:

de animation looping knop
FPS = snelheid van de animatie (frames per seconde)
play knop om een voorbeeld te zien
add frame from file knop om losse afbeeldingen toe te voegen.

Klik op de add frame from file. In de dialoog die volgt, zoek de map met de juiste afbeeldingen en gebruik shift-muisklik om ze allemaal te selecteren.
(Klik op de eerste afbeelding, houdt dan SHIFT ingedrukt en klik op de laatste afbeelding)

Voeg de juiste beelden toe aan alle animaties, en stel de juiste opties in:

alle animaties spelen aan 30 FPS.
'idle' en 'walk' hebben animation looping AAN staan (knop icoon is blauw)
'attack', 'hurt', 'die' hebben het UIT staan (knop icoon heeft zelfde kleur als andere knoppen). Deze animaties spelen maar 1 keer, tot we via code een nieuwe animatie starten.

Nu gaan we voor de eerste keer code gebruiken, om onze 'Player' tot leven te brengen!
In het linkerpaneel zorgen we dat de 'Player' geselecteerd is, en klikken we op de knop Attach script.

We krijgen een dialoog, waar we een template (voorbeeld) kunnen kiezen, en een naam voor het script. Omdat we onze node 'Player' hebben genoemd, krijgen we automatisch de naam 'Player.gd' als standaard, wat prima is. Klik Create.

Je krijgt van Godot nu wat voorbeeldcode voor een platformer, met springen. We hebben springen niet nodig. Je mag alle code wegdoen, behalve de eerste 2 regels:

extends CharacterBody2D

const SPEED = 300.0

Omdat we dit script verbinden met onze player node, en dat een CharacterBody2D is, start het script met de regel extends CharacterBody2D.

De tweede regels is de definitie van een constante: we gaan het woord 'SPEED' later in ons script gebruiken, en daar wordt overal de waarde '300' ingevuld. Dit is de loop-snelheid van onze speler. We maken er '400' van.

const SPEED = 400.0

We willen dat de speler onze 'held' kan laten bewegen. Hij moet kunnen links-rechts en boven-onder bewegen met de pijltoetsen. Deze logica gaan we in de _physics_process functie steken: dit is een functie die de Godot engine oproept voor elke game tick. Standaard is dit 60 maal per seconde. Deze snelheid is vast en hangt niet af van de kracht van je grafische kaart. We willen dat onze speler overal even snel loopt, of je nu een krachtige grafische kaart hebt of niet.

func _physics_process(_delta):
    velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
    velocity.y = Input.get_axis("ui_up", "ui_down") * SPEED
    move_and_slide()

We kunnen dit al testen.
Ga terug naar de game scene en sleep de player.tscn naar de 'Arena' node, als kind van de node.

Klikken we nu op Run Project rechtsboven, dan opent onze game en kunnen we met de pijltoetsen onze speler bewegen!

Er zijn nog een paar basis zaken die ontbreken:

het personage zelf beweegt niet
het personage kijkt altijd naar dezelfde kant
het personage kan 'buiten beeld' lopen.

De eerste 2 punten kunnen we snel oplossen met wat extra code.

Ga terug naar het script via de Script knop boven-midden.

We hebben daarstraks de animaties reeds gemaakt, nu moeten we enkel nog de juiste animatie starten vanuit onze code. Wanneer de speler loopt, spelen we de 'walk' animatie. Als hij stilstaat, spelen we 'idle'.

De animaties worden getoond door de AnimatedSprite2D die we aan onze player scene hebben gehangen. In onze code gaan wie deze node zoeken en opslaan in een variabele die we 'sprite' noemen. Dit stukje code komt vlak onder onze constante SPEED te staan, en wordt eenmaal uitgevoegd als het spel start:

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

In onze _physics_process functie kunnen we nu de variabele sprite gebruiken om een animatie te starten.

We vervangen het stukje move_and_slide() door deze blok code:

    if velocity:
        move_and_slide()
        sprite.play("walk")
    else:
        sprite.play("idle")

Onze code ziet er dan zo uit:

extends CharacterBody2D

const SPEED = 400.0

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

func _physics_process(_delta):
    velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
    velocity.y = Input.get_axis("ui_up", "ui_down") * SPEED

    if velocity:
        move_and_slide()
        sprite.play("walk")
    else:
        sprite.play("idle")

Test of het werkt via die Run Project knop of de F5 toets.
Het is vaak een goed idee je code te testen na elke kleine wijziging.

De kijkrichting van de speler wijzigen doen we via een trukje. Je kan de schaal (grootte) van een afbeelding wijzigen, en zelfs de hoogte (y) en breedte (x) apart. Schaal 1 is de originele grootte. Schaal 2 is dan dubbel zo groot. Maar schaal -1 is originele grootte, maar gespiegeld. Als we de sprite schaal voor x veranderen van 1 naar -1 wordt de sprite gespiegeld in de breedte.

Aan onze _physics_process functie voegen we het volgende stukje code toe (onder de regels waar velocity.x en velocity.y worden ingesteld via Input.get_axis):

if velocity.x < 0:
    sprite.scale.x = -1
elif velocity.x > 0:
    sprite.scale.x = 1

De hele code ziet er nu zo uit:

extends CharacterBody2D

const SPEED = 400.0

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

func _physics_process(_delta):
    velocity.x = Input.get_axis("ui_left", "ui_right") * SPEED
    velocity.y = Input.get_axis("ui_up", "ui_down") * SPEED

    if velocity.x < 0:
        sprite.scale.x = -1
    elif velocity.x > 0:
        sprite.scale.x = 1

    if velocity:
        move_and_slide()
        sprite.play("walk")
    else:
        sprite.play("idle")

Als je het project test, merk je dat het personage nu ook kijkt in de juiste richting als hij loopt.

Er voor zorgen dat onze speler niet 'buiten beeld' kan lopen doen we in het volgende deel.

Een beat-em-up game maken met Godot - de wereld

Bgie — Fri, 07 Apr 2023 18:38:34 +0000

In deze tutorial maken we een eenvoudige beat-em-up game met Godot 4.

NOTE: if anyone cares for an English version, msg me.

Downloads

Zorg eerst dat je Godot geinstalleerd hebt: https://godotengine.org/
Deze tutorial is gemaakt met versie 4.0.1. Je hebt minstens Godot 4 nodig, een 3.x versie is te verschillend!
Met een hogere versie moet het (normaal) wel lukken.

Verder heb je de game assets nodig. Deze zijn gratis te downloaden via craftpix. Volg je deze tutorial via CoderDojo, dan kan je een USB stick vragen aan de coach.

Download de volgende assets (blauwe 'free download' knop), en pak de zipfiles uit:

De game assets bevatten meerdere varianten voor de achtergrond of karakters, die kan je ook gebruiken voor deze tutorial, dan ziet jouw game er niet hetzelfde uit.

Nieuw project maken

Als we Godot openen krijgen we eerst de Project Manager.
In deze tutorial staat de taal van Godot op Engels. Dat is makkelijker wanneer je hulp zoekt op het internet. Maar je kan de user interface in het Nederlands zetten. De programmeertaal blijft wel op Engels gebaseerd.

We maken een nieuw project via de New Project knop.

In de dialoog geven we ons project een naam bij Project Name en klikken we op Create Folder om de nieuwe map te maken voor ons project.
(Indien nodig kan je eerst bij Project Path kiezen waar je nieuwe map terecht komt.)

Na het maken van de nieuwe map kiezen we Create & Edit.

Het hoofdvenster van Godot opent. De belangrijkste onderdelen op het scherm zijn:

De hoofdnavigatie: we gaan enkel 2D view en script gebruiken in deze tutorial.
De scene tree: een boom met alle onderdelen in de huidige scene. Dit wordt later duidelijk.
Het file system: waar alle bestanden te zien zijn die ook op je harde schrijf staan, zoals de afbeeldingen, scripts en scenes in je project.
De inspector waar je de properties (eigenschappen) te zien krijgt van het geselecteerde object in je scene.
De knoppen vanonder tonen verschillende extra panelen om allerlei editors te openen, afhankelijk welk object in de scene geselecteerd is.

Het middenstuk van het scherm toont de game scene zelf (als 2D gekozen is) of toont het script waar je aan werkt (als Script gekozen is)

Omdat we een leeg project hebben, is er niet veel te zien, maar wanneer als je een bestaande game open hebt, ziet dit scherm er zo uit:

Game assets kopiëren

We gaan eerst onze graphics kopiëren.
Door rechts te klikken op res:// in het FileSystem paneel openen we een menu. Daar kunnen we Open in File Manager kiezen om een verkenner venster te krijgen. Dit hangt af van je besturingssysteem (Windows, Mac, Linux).

Kopieer de juiste submappen vanuit je downloads:

Downloads/craftpix-net-270096-free-forest-battle-backgrounds/PNG/game_background_1
Downloads/craftpix-991117-free-fallen-angel-chibi-2d-game-sprites/Fallen_Angels_2/PNG/PNG Sequences
Downloads/craftpix-net-484869-free-minotaur-tiny-style-2d-sprites/PNG/Minotaur_01/PNG Sequences

... naar je Godot project map die we net openden. Ik heb zelf mapjes gemaakt met duidelijke namen om alles makkelijk terug te vinden.

Een scene maken met nodes

We starten met een eenvoudige achtergrond en een vaste camera, die niet beweegt.

Onze scene heeft een root node nodig, het beginpunt van alles. Omdat onze game 2D is, kiezen we voor een 2D Scene:

Met de + (plus) knop kunnen we nodes toevoegen aan onze scene.

Nu krijgen we de Create New Node dialoog waar we moeten aangeven welke soort node we willen toevoegen. Via het zoekvak boven kiezen we voor een Sprite2D, dit is de soort node voor een gewone, 2D tekening zonder animaties.

Onze nieuwe node komt bij in de scene tree.

We maken nog een aantal nodes bij: een StaticBody2D, nog een Sprite2D, en een Camera2D.
Let erop dat alle nieuwe nodes op hetzelfde niveau zitten. Je kan een node 'onder' een andere node hangen. We willen al onze nodes onder de root node. De volgorde van de nodes is ook belangrijk.

Voor de duidelijkheid gaan we onze nodes een goede naam geven. Dit doe je door een node aan te klikken, even te wachten, en opnieuw te klikken. Je kan ook rechts klikken en Rename kiezen of F2 gebruiken.

de root node wordt 'Game'
de eerste sprite wordt 'Background'
de static body wordt 'Arena'
de tweede sprite wordt 'Foreground'
de camera noemen we gewoon 'Camera'

Dit is een goed moment om op te slaan. Dit kan met Ctrl+S of in de hoofdmenu Scene - Save Scene.
Omdat dit de eerste keer is, krijgen we een dialoog. De naam 'Game' van onze root node is een goede naam voor de scene. Klik gewoon Save.

Achtergrond en camera

De achtergrond afbeelding instellen is nu makkelijk: klik links om de 'Background' node te selecteren, en klik dan in het Inspector paneel op het kleine pijltje naar beneden bij Texture: <empty>. In het menu kies je helemaal beneden voor Load.

Je krijgt een dialoog waar we bladeren tot we game_background_1.png hebben gevonden. Bij mij is het pad res://assets/background/game_background_1.png omdat ik een submap assets heb gemaakt.

Voor de 'Foreground' sprite doen we hetzelfde, maar we gebruiken een andere afbeelding: enkel de voorste laag van ons bos, waar er vanonder een strookje gras staat met een dikke steen: res://assets/background/front_decor.png.

Door met 2 sprites te werken kunnen later onze karakters achter het voorste gras lopen, wat er realistischer uitziet.

Je kan controleren of de twee sprites correct zijn door ze tijdelijk onzichtbaar te maken. Als de 'Background' sprite onzichtbaar is, moet je enkel de strook gras op de voorgrond zien.

Laatste stap in het instellen van de camera: voor dit eenvoudige spel staat de camera gewoon stil. Maar onze achtergrond afbeelding is erg groot, we gaan de camera wat uitzoomen.

Selecteer de 'Camera' node en stel rechts de Zoom in op 0.5. Beide waarden zijn verbonden, dus je moet dit maar 1 keer doen.

We hebben nu het minimum gedaan om onze 'game' te kunnen testen. Klik op de Run Project knop of druk F5.

Omdat dit de eerste keer is dat we onze game uitvoeren, vraagt Godot welke scene de opstart-scene moet worden. We hebben maar 1 scene ('Game') en dat is de huidige. Dus kies gewoon Select Current.

Na een laad-scherm start onze game. Standaard is het venster 1152x648 pixels groot.

Je kan het venster maximaliseren, en dan zou je de hele afbeelding van het bos moeten zien, als je computermonitor op HD 1920x1080 staat.

Tot zover deel 1.
In deel 2 gaan we onze speler toevoegen en tot leven brengen met code.