Skip to content
  • English
  • Polski
Digital Karabela
Digital Karabela
Primary Navigation Menu
Menu
  • Strona główna
  • Produkty
  • DevBlog
  • Castle Engine
  • Kurs bash
  • O firmie

Godot 3.1 – Powrót do tworzenia gier mobilnych i statyczne typy w GDScript

Godot logo (CC-BY 3.0)

Po 11 betach i 3 wersjach RC Godot 3.1 ujrzał światło dzienne. Prace nad nim trwały 14 miesięcy, czyli 4 miesiące krócej od prac nad rewolucyjną wersją 3.0.

Powrót do mobile

Jeżeli próbowałeś użyć wersji 3.0 do stworzenia gry mobilnej prawdopodobnie szybko natrafiłeś na błędy/ograniczenia w sterownikach OpenGL ES 3.0. Np. na moim Redmi Note 4 nie wyświetlały się efekty cząsteczkowe (Particles i Particles2D) co skutecznie zniechęciło mnie do użycia wersji 3.0. Nowa wersja Godota rozwiązuje ten problem dodając nowy renderer GLES2 z cząsteczkami liczonymi przez CPU (CPUParticles i CPUParticles2D). Należy jednak pamiętać aby całą grę tworzyć z użyciem GLES2 ponieważ niektóre funkcjonalności GLES3 nie są dostępne w GLES2.

Opcjonalne statyczne typowanie w GDScript:

Drugą nowością, którą na pewno wykorzystam są statyczne typy w GDScript. Siła Godota leży w łatwym prototypowaniu. Elastyczny system scen wraz z pythonowym językiem GDScript pozwala na szybkie sprawdzanie różnych idei i mechanik. Dodatkowo dynamiczne typowanie znacznie przyspiesza takie eksperymenty. Przy większych projektach może to jednak prowadzić do błędów, spadku wydajności/komfortu programisty (brak podpowiedzi w trakcie pisania kodu) i utrudnia refaktoryzację.

Aby rozwiązać ten problem wprowadzono możliwość określenia typu zmiennych i funkcji. Czyli nadal można łatwo i przyjemnie tworzyć prototypy, po czym uszczegółowić wersję docelową podając typy. W przyszłości te informacje mają także zostać wykorzystane do optymalizacji skryptów podczas kompilacji.

Statyczne typowanie w zmiennych

Typ zmiennej podajemy po dwukropku:

var zmienna_int : int = 5

Inferencja typów

Dodatkowo typ może być pobrany z przypisywanej wartości, wtedy nie musimy go zapisywać po dwukropku:

var wektor : = Vector2(1, 1)

Statyczne typowanie w funkcjach

Typy parametrów podobnie jak w zmiennych dodajemy po dwukropku. Typ zwracany zapisujemy na końcu po strzałce „->” np.:

func nazwa_funkcji(zmienna : int) -> String:

Bezpieczne linie i rzutowanie

Ponieważ można mieszać typowany kod z nietypowanym. W edytorze zostały wprowadzone tzw. bezpieczne linie. Kod statycznie typowany ma numery linii zapisane na zielono. Linie kodu dynamicznie typowanego mają szare numery linii. Na pierwszy rzut oka jest to taki bajer. W rzeczywistości bardzo pomaga w debugowaniu kodu i wychwytywaniu trudnych do zauważenia problemów np:

Jeżeli pobierzemy sobie węzeł typu VBoxContainer i zapiszemy go w zmiennej typu Node:

var n : Node = $vbox_node

a następnie przypiszemy go do zmiennej s1 typu Sprite:

var s1 : Sprite = n
if s1:
	s1.texture = null

Moglibyśmy się spodziewać, że zostanie wyświetlony komunikat błędu lub zmienna będzie zawierać pusty wskaźnik ze względu na niezgodność typów. Niestety nic takiego się nie stanie. Parser to przepuści, a zmienna s1 będzie miała wskaźnik do VBoxContainer! Po uruchomieniu program zostanie zakończony błędem w trakcie wykonywania linii s1.texture = null. W takim przypadku numer linii 19 będzie szary (dynamiczne typowanie):

19 linia nie jest bezpieczna (statycznie typowana)

Aby użyć w pełni zalet statycznego typowania należy rzutować typ zmiennej jawnie (w przypadku niezgodnych typów zmienna będzie wskazywała na null):

var s2 : Sprite = n as Sprite
if s2:
	s2.texture = null

W tym przypadku numer linii będzie koloru zielonego, a linia kodu s2.texture = null zostanie pominięta.

Sprawdzanie typu

Gdy chcemy sprawdzić typ możemy korzystać z operatora as np:

func clear_texture(n: Node) -> void:
	sp : Sprite =  n as Sprite
	if sp:
		sp.texture = null

Istnieje także operator is, który pozwala skrócić kod, lecz nie rzutuje typu więc tracimy dostęp do pełnego podpowiadania składni:

func clear_texture(n: Node) -> void:
	if n is Sprite:
		n.texture = null

Inne zmiany

Znacząco ulepszono sam edytor (w tym inspektor, edytor 2D i 3D, edytor animacji, widok systemu plików), całość sprawia wrażenie o wiele stabilniejszego i dojrzalszego produktu. Powrócił wizualny edytor shaderów. Wprowadzono deformacje w animacjach 2D, algorytm szumów opensimplex, CSG dla szybkiego prototypowania 3D i wiele wiele innych.

Patreon

Twórców można wesprzeć zostając patronem.

2019-04-01
1 kwietnia, 2019
W Godot, Tworzenie gier
Tagi: android, gamedev, godot, godotengine, iOS, mobiledev
Poprzedni wpis: Agile Commander – Wiosenna promocja
Następny wpis: Pierwsze wydanie kandydujące Godota 3.1.1

Wypróbuj moją nową grę! Zupełnie za darmo!

Logo Bricks Color Pick

Bricks Color Pick to zupełnie nowe podejscie do klasycznego arkanoida! Brak dolnej belki! Zasady gry są bardzo proste: Twoim zadaniem jest zmienianie koloru piłki na kolor cegły, z którą piłka się zderzy. Gdy kolor będzie taki sam cegła zostanie zniszczona, w przeciwnym wypadku stracisz życie.

Pobierz z Google Play

Zrzut ekranu pozimu 37/40 5-6 kolorów

Dodatkowo można zmienić kierunek ruchu piłki, przez co nie musimy czekać wieczność aż trafi w ostatni blok.

QR Code Google Play Bricks Color Pick

Zrzut ekranu poziom 62/80 (Tryb relaks)

Ostatnie wpisy

  • Jak skompilować bibliotekę OpenAL z Oboe dla systemu Android
  • Lazarus 2.0.12 wydany
  • Jak naprawić zamrażanie GUI LMMS w systemie Linux?
  • Jak zaktualizować wine do wersji 5.0.0 w Linux Mint 19 / Ubuntu 18
  • Agile Commander 1.2.3 wydany!

Kategorie

  • DevBlog
  • Linux
    • Kurs bash
    • Narzędzie WoeUSB
  • Programowanie
    • Język D (dlang)
      • Kontrolki DlangUI
    • Język Object Pascal
      • Lazarus (pl)
    • Narzędzie make
  • Promocja
  • Tworzenie gier
    • Castle Engine (pl)
    • Godot
  • Windows 10
    • Narzędzie WoeUSB

Produkty:
Agile Commander
Bricks Color Pick

 

 

Digital Karabela – Andrzej Kilijański
76-015 Wyszebórz 32, Poland
https://digitalkarabela.com
Kontakt
Polityka prywatności