Prechádzať zdrojové kódy

Added Polish translation to Introduction, Building Blocks and Lifecycle (#106)

* Initial commit for polish translations. Starting with translating manuals. Images and assets copied as is. Translated: 2d-graphics, 3d-graphics, adapting-to-different-screen-sizes, ads, adrressing, android. Created a translated pl.json.

* Enable Polish

* Removed images from everything but master folder (en)

* Update README.md

* Moved Facebook docs to Facebook extension

* Greek manuals (#103)

* Moved instant games documentation

* Activated Greek

* Fixed broken frontmatter

* Added Polish translation to Introdution, Building Blocks and Application licecycle. Made small corections to existing Polish manuals

Co-authored-by: Björn Ritzl <[email protected]>
Co-authored-by: Elpidoforos Gkikas <[email protected]>
paweljarosz 5 rokov pred
rodič
commit
68b1a8cf46

+ 12 - 12
docs/pl/manuals/addressing.md

@@ -5,11 +5,11 @@ brief: Instrukcja wyjaśnia sposób adresowania w silniku Defold.
 
 # Adresowanie
 
-Kod, który kontroluje grę musi obejmować zasięgiem wszystkie obiekty i komponenty, aby poruszać, skalować, animować, usuwać czy manipulować co gracz widzi i słyszy. Umożliwia to mechanizm adresowania w silniku Defold.
+Kod, który kontroluje grę musi sięgać do wszystkich obiektów i komponentów, aby poruszać, skalować, animować, usuwać czy manipulować tym, co gracz widzi i słyszy. Umożliwia to mechanizm adresowania w silniku Defold.
 
 ## Identyfikatory
 
-Defold wykorzystuje adresy (tzw. URL z ang. Uniform Resource Locator)) aby odnosić się do obiektów i komponentów. Te adresy składają się z identyfikatorów (ID). Poniżej przedstawiono wszystkie przykłady tego, jak Defold wykorzystuje adresy. W tej instrukcji przeanalizujemy je szczegółowo:
+Defold wykorzystuje adresy (tzw. URL z ang. Uniform Resource Locator), aby odnosić się do obiektów i komponentów. Te adresy składają się z identyfikatorów (ID). Poniżej przedstawiono wszystkie przykłady tego, jak Defold wykorzystuje adresy. W tej instrukcji przeanalizujemy je szczegółowo:
 
 ```lua
 local id = factory.create("#enemy_factory")
@@ -35,16 +35,16 @@ end
 ```
 1. Nie przejmuj się na tę chwilę znakiem '#'. Powrócimy do tego.
 
-Będzie to działać tak jak oczekiwaliśmy. Gdy gra się uruchomi, skrypt *adresując* komponent typu sprite poprzez jego identyfikator "body" i użyje tego adresu aby wysłać do niego specjalną *wiadomość* o treści "disable" (ang. wyłącz). Efektem tej specjalnej wiadomości silnika jest to, że w komponencie sprite zostanie ukryty/wyłączony. Schematowo, ustawienie wygląda następująco:
+Zadziała to tak, jak oczekiwaliśmy. Gdy gra się uruchomi, skrypt *adresując* komponent typu sprite poprzez jego identyfikator "body" użyje tego adresu, aby wysłać do niego specjalną *wiadomość* o treści "disable" (ang. wyłącz). Efektem tej specjalnej wiadomości silnika jest to, że w komponencie sprite zostanie ukryty/wyłączony. Wygląda to następująco:
 
 ![bean](images/addressing/bean.png)
 
-Identyfkatory w ustawieniu są arbitralne. Tutaj, my wybraliśmy aby nadać obiektowi identyfikator "bean" (ang. fasola), a jego komponent typu sprite ma identyfikator "body" (ang. ciało), a skrypt kontrolujący postać został nazwany "controller".
+Identyfkatory w takim ustawieniu są arbitralne. Tutaj, to my zdecydowaliśmy, aby nadać obiektowi identyfikator "bean" (ang. fasola), a jego komponentowi typu sprite - identyfikator "body" (ang. ciało). Skrypt kontrolujący postać został nazwany "controller".
 
 ::: sidenote
-Jeśli sam nie wybierzesz identyfikatora, edytor zrobi to za Ciebie. Kiedykowliek tworzysz nowy obiekt lub komponent w edytorze zostaje mu przydzielony z góry unikalny *Id*.
+Jeśli sam nie wybierzesz identyfikatora, edytor zrobi to za Ciebie. Kiedy tworzysz nowy obiekt lub komponent w edytorze, zostaje mu z góry przydzielony unikalny *Id*.
 
-- Obiekty (ang. game objects) mają z góry przypisany Id "go" z numerem ("go2", "go3" itd.).
+- Obiekty (ang. game objects) mają z góry przypisane Id "go" z numerem ("go2", "go3" itd.).
 - Komponenty dostają Id odpowiadające typowi ("sprite", "sprite2", "label", "sound" itp.).
 
 Oczywiście możesz pozostać przy tak wygenerowanych nazwach, ale zachęcamy do ich zmiany na dobre, opisowe i znaczące nazwy.
@@ -64,7 +64,7 @@ Jeśli spróbujesz nadać nieunikalną nazwę, edytor i tak zasygnalizuje błąd
 ![bean](images/addressing/name_collision.png)
 :::
 
-Zobaczmy teraz co się stanie, gdy dodamy więcej obiektów. Załóżmy, że chcesz stworzyć małą drużynę "fasolek". Decydujesz się nazwać jeden z obiektów "bean", a drugi "buddy" (ang. kolega). Ponadto, kiedy "bean" będzie przez chwilę bezczynny, powinien powiedzieć swojemu koledze "buddy", aby zaczął tańczyć. Można to zrobić przez wysłanie niestandradowej wiadomości o treści "dance" (ang. tańcz) ze skryptu "controller" obiektu "bean" do skryptu "controller" obiektu "buddy":
+Zobaczmy teraz co się stanie, gdy dodamy więcej obiektów. Załóżmy, że chcesz stworzyć małą drużynę "fasolek". Nazwaliśmy jeden z obiektów "bean", to drugi nazwijmy "buddy" (ang. kolega). Ponadto, kiedy "bean" będzie przez chwilę bezczynny, chcemy, żeby powiedział on swojemu koledze "buddy", aby zaczął tańczyć. Można to zrobić przez wysłanie niestandradowej wiadomości o treści "dance" (ang. tańcz) ze skryptu "controller" obiektu "bean" do skryptu "controller" obiektu "buddy":
 
 ![bean](images/addressing/bean_buddy.png)
 
@@ -72,7 +72,7 @@ Zobaczmy teraz co się stanie, gdy dodamy więcej obiektów. Załóżmy, że chc
 Są tutaj dwa komponenty typu skrypt nazwane "controller", ale każdy w osobnym obiekcie, więc jest to całkowicie dozwolone, ponieważ ich całkowite nazwy (adresy) uwzględniające identyfikatory obiektów są od siebie różne. Nowy obiekt tworzy więc tzw. nowy kontekst nazewniczy.
 :::
 
-Ponieważ wysyłamy wiadomość do komponentu poza naszym obiektem ("bean"), w kodzie musimy określić, do którego komponentu "controller" nasza wiadomość powinna być wysłana. Musimy więc w tym przypadku określić zarówno identyfikator obiektu (game object id) i komponentu (component id). Pełny adres komponentu "controller" z obiektu "buddy" brzmi więc: `"buddy#controller"` i adres ten składa się z dwóch części.
+Ponieważ wysyłamy wiadomość do komponentu poza naszym obiektem ("bean"), w kodzie musimy dookreślić, do którego komponentu "controller" nasza wiadomość powinna być wysłana. Musimy więc w tym przypadku określić zarówno identyfikator obiektu (game object id) i komponentu (component id). Pełny adres komponentu "controller" z obiektu "buddy" brzmi więc: `"buddy#controller"` i adres ten składa się z dwóch części.
 
 - Najpierw określamy identyfikator obiektu ("buddy"),
 - następnie wstawiamy wspomniany już znak oddzielenia id obiektu od komponentu ("#"),
@@ -105,7 +105,7 @@ Adres `"buddy#controller"` działa dla obiektów z obu kolekcji, ponieważ jest
 ![relative id](images/addressing/relative_same.png)
 
 - W obrębie kontekstu nazewniczego kolekcji "team_1", obiekty "bean" i "buddy" mają unikalne adresy.
-- Analogicznie, W obrębie kontekstu nazewniczego kolekcji "team_2", obiekty "bean" i "buddy" mają również unikalne adresy.
+- Analogicznie, w obrębie kontekstu nazewniczego kolekcji "team_2", obiekty "bean" i "buddy" mają również unikalne adresy.
 
 Adresowanie relatywne (względne) działa dzięki automatycznemu używaniu identyfikatora własnej, obecnej kolekcji (czy też własnego kontekstu nazewniczego) przy tworzeniu adresu każdego komponentu. Jest to również niezwykle przydatne, ponieważ możesz tworzyć grupy obiektów z tym samym kodem dla każdego z nich i wykorzystywać je wielokrotnie w grze.
 
@@ -130,7 +130,7 @@ Dla przykładu powyżej, gra uruchomi się startując z 4 obiektami:
 - /team_2/buddy
 
 ::: sidenote
-Adresy komponentów są przechowywane jako "posiekane" / "skrócone" (ang. hashed - i może lepiej jako programista używać angielskiej nazwy (hash)[https://pl.wikipedia.org/wiki/Funkcja_skrótu]- przyp. tłumacza) wartości. W czasie działania program przechowuje adresy również jako "shaszowane" dla każdej instancji w kolekcji, która jest w użyciu, aby zachować ciągłość nazwy adresu absolutnego (bezwzględnego).
+Adresy komponentów są przechowywane jako "posiekane" lub "skrócone" (ang. hashed - i może lepiej jako programista używać angielskiej nazwy (hash)[https://pl.wikipedia.org/wiki/Funkcja_skrótu]- przyp. tłumacza) wartości. W czasie działania program przechowuje adresy również jako "shaszowane" dla każdej instancji w kolekcji, która jest w użyciu, aby zachować ciągłość nazwy adresu absolutnego (bezwzględnego).
 :::
 
 W czasie działania programu, grupowanie kolekcji nie istnieje. Nie ma sposobu na sprawdzenie do jakiej kolekcji przynależy dany obiekt przed kompilacją. Nie jest też możliwe manipulowanie wszystkimi obiektami w kolekcji naraz. Jeśli jednak potrzebujesz wykorzystywać takie operacje  możesz z łatwością śledzić adres w kodzie. Każdy identyfikator obiektu jest statyczny, jest więc gwarantowane, że zostanie stały przez cały cykl życia obiektu. Oznacza to, że można bezpiecznie przechować id obiektu i używać go później.
@@ -203,7 +203,7 @@ path
 fragment
 : Identyfkator danego komponentu pod danym obiektem.
 
-Tak jak wcześniej, możesz zostawić niektóre pola puste pozwalając silnikowi na wydedukowanie, o jaki element chodzi zakładając domyślne wartości jak powyżej. Bardzo rzadko jest potrzeba określania socketu, za to często musisz określić path. W przypadkach, gdy chcesz się odnieść do obiektu z innego świata (kolekcji) niż obecna, będziesz podawać socket.Przykładowo, pełny URL skryptu "controller" obiektu "manager" wygląda następująco:
+Tak jak wcześniej, możesz zostawić niektóre pola puste pozwalając silnikowi na wydedukowanie, o jaki element chodzi zakładając domyślne wartości jak powyżej. Bardzo rzadko jest potrzeba określania gniazda (socket), za to często musisz określić ścieżkę (path). W przypadkach, gdy chcesz się odnieść do obiektu z innego świata (kolekcji) niż obecna, będziesz podawać socket. Przykładowo, pełny URL skryptu "controller" obiektu "manager" wygląda następująco:
 
 `"main:/manager#controller"`
 
@@ -243,4 +243,4 @@ my_url.fragment = "controller" -- specify as string or hash
 
 -- Post to target specified by URL
 msg.post(my_url, "hello_manager!")
-```
+```

+ 481 - 0
docs/pl/manuals/animation.md

@@ -0,0 +1,481 @@
+---
+title: Animacja w silniku Defold
+brief: Instrukcja opisuje wsparcie dla animacji w silniku Defold.
+---
+
+# Animacja
+
+Defold posiada wbudowane wsparcie dla różnych typów animacji, których możesz używać jako źródło dla komponentów graficznych:
+
+* Animacja poklatkowa (Flip-book)
+* Animacja szkieletowa 2D (Spine)
+* Animacja szkieletowa 3D (3D skinned)
+* Animacja właściwości
+
+## Flip-book - animacja poklatkowa
+
+Animacja poklatkowa składa się z serii obrazów, które są pokazywane jeden za drugim, więc patrząc na nie sprawiają wrażenie ruchu. Technika ta jest bardzo podobna do tradycyjnej animacji używanej w kinematografii [https://pl.wikipedia.org/wiki/Animacja](https://pl.wikipedia.org/wiki/Animacja) i oferuje nieograniczoną kontrolę, ponieważ każda klatka może być modyfikowana indywidualnie. Jednakże pamięć zajmowana przez wszystkie obrazy składające się na taką animację może być duża w zależności od ilości klatek i ich wielkości. Płynność animacji zależy od liczby klatek pokazywanych w każdej sekundzie (FPS z ang. frames per second), co wymaga oczywiście większej ilości pracy. Animacje typu flip-book w Defoldzie są przechowywane albo jako indywidualne obrazy umieszczone w galerii zwanej [Atlas](/manuals/atlas), albo jako obrazy umieszczone w bezpośrednim sąsiedztwie, w poziomej sekwencji jak kafelki w tzw. [Tile Source](/manuals/tilesource).
+
+  ![Animation sheet](images/animation/animsheet.png){.inline}
+  ![Run loop](images/animation/runloop.gif){.inline}
+
+## Spine - animacja szkieletowa
+
+Wsparcie dla animacji typu Spine w Defoldzie umożliwia tworzenie animacji szkieletowych z obrazów 2D (https://pl.wikipedia.org/wiki/Rigging). Jest to zupełnie inna technika niż animacja flip-book i bliżej jej do płynnych ruchów, bez podzielenia obrazu na poszatkowane klatki. Przykładowo w animacjach wykorzystujących wycinanki [https://en.wikipedia.org/wiki/Cutout_animation](https://en.wikipedia.org/wiki/Cutout_animation) osobne części (np. korpus, ramiona, nogi, oczy itp.) są poruszane indywidualnie w każdej klatce z zachowaniem stałego szkieletu i określonych połączeń między częściami, np. przegubów. Animacja typu Spine umożliwia stworzenie właśnie takiego wirtualnego, niewidzialnego szkieletu składającaego się z hierarchii konkretnie połączonych części - _kości_ (ang. bones) połączonych w łańcuchy kinematyczne. Taki szkielet, czy z ang. _rig_, jest właśnie animowany i przyczepione są do każdej z kości odpowiednie części - obrazy. Defold wspiera animacje stworzone w lub wyeksportowane do [formatu Spine JSON](http://esotericsoftware.com/spine-json-format). Animacja szkieletowa jest zwykle bardzo płynna, ponieważ silnik interpoluje położenie i orientację każdej z "kości" dla każdej klatki.
+
+  Szczegóły dotyczące importowania danych z programu Spine do komponentu "Spine model" w Defoldzie znajdziesz tutaj: [Instrukcja Spine](/manuals/spine).
+
+  ![Spine animation](images/animation/spine_animation.png){.inline}
+  ![Run loop](images/animation/frog_runloop.gif){.inline}
+
+## Animacja szkieletowa 3D
+
+Animacja szkieletowa trójwymiarowych modeli jest podobna do animacji typu Spine, z tym, że działa również w trójwymiarze. Model 3D nie jest jednak podzielony na osobne części związane ze sobą w łańcuch kinematyczny, a w zamian tego, ruch "kości" deformuję siatkę wierzchołków (ang. vertices) reprezentującą obiekt 3D, a Ty masz kontrolę nad tym w jaki sposób kości wpływają na taką deformację.
+
+  Szczegóły dotyczące importowania danych 3D do komponentu "Model" w Defoldzie znajdziesz tutaj: [Instrukcja Modeli 3D](/manuals/model).
+
+  ![Blender animation](images/animation/blender_animation.png){.inline srcset="images/animation/[email protected] 2x"}
+  ![Wiggle loop](images/animation/suzanne.gif){.inline}
+
+## Animacja właściwości
+
+Wszystkie numeryczne właściwości (liczby, wektory (vector3, vector4) i kwaterniony) i stałe [shader'ów](https://pl.wikipedia.org/wiki/Shader) mogą być animowane przez wbudowany system animacji, używając funkcji [`go.animate()`](https://defold.com/ref/stable/go/#go.animate). Defold automatycznie "wyśrodkuje" właściwości dla Ciebie w zależności od podanego sposobu odtwarzania (ang. playback) czy funkcji "wygładzania" (ang. easing - więcej: [Easing functions](https://easings.net)) predefiniowanych lub Twoich własnych.
+
+  ![Property animation](images/animation/property_animation.png){.inline srcset="images/animation/[email protected] 2x"}
+  ![Bounce loop](images/animation/bounce.gif){.inline}
+
+## Odtwarzanie animacji poklatkowych (flip-book)
+
+Sprite'y i węzły interfejsu GUI mogą odtwarzać animacje poklatkowe i masz nad tym całkowitą kontrolę w trakcie działania programu.
+
+Sprite'y
+: Aby odtworzyć animację w trakcie działania programu używa się funkcji [`sprite.play_flipbook()`](/ref/sprite/?q=play_flipbook#sprite.play_flipbook:url-id-[complete_function]-[play_properties]). Poniżej przykład.
+
+Węzły interfejsu GUI
+: Aby odtworzyć animację w trakcie działania programu używa się funkcji [`gui.play_flipbook()`](/ref/gui/?q=play_flipbook#gui.play_flipbook:node-animation-[complete_function]-[play_properties]). Poniżej przykład.
+
+::: sidenote
+Tryb odtwarzania (playback mode) "once ping-pong" odtworzy animację klatka po klatce do samego końca, a następnie odtworzy ją jeszcze raz w odwrotnej kolejności, od tyłu, ale do **drugiej** klatki animacji, a nie do pierwszej. Jest to zabieg służący łatwemu wiązaniu animacji w łańcuchy.
+:::
+
+### Przykład animacji poklatkowej ze spritem
+
+Załóżmy, że Twoja gra posiada możliwość uniku, która pozwala graczom nacisnąć klawisz, aby wykonać unik. Możesz wykonać 4 animacje, żeby w pełni pokazać unik:
+
+"idle"
+: Zapętlona animacja stojącej postaci będącej w bezczynności.
+
+"dodge_idle"
+: Zapętlona animacja postaci pochylonej, będącej w trakcie trwania uniku.
+
+"start_dodge"
+: Jednokrtotnie odtwarzana animacja postaci w momencie przejścia animacji z pozycji stojącej do pochylonej w celu wykonania uniku.
+
+"stop_dodge"
+: Jednokrtotnie odtwarzana animacja postaci w momencie przejścia animacji z pozycji uniku z powrotem do pozycji stojącej.
+
+Skrypt poniżej przedstawia potrzebną logikę:
+
+```lua
+
+local function play_idle_animation(self)
+    if self.dodge then
+        sprite.play_flipbook("#sprite", hash("dodge_idle"))
+    else
+        sprite.play_flipbook("#sprite", hash("idle"))
+    end
+end
+
+function on_input(self, action_id, action)
+    -- "dodge" is our input action
+    if action_id == hash("dodge") then
+        if action.pressed then
+            sprite.play_flipbook("#sprite", hash("start_dodge"), play_idle_animation)
+            -- remember that we are dodging
+            self.dodge = true
+        elseif action.released then
+            sprite.play_flipbook("#sprite", hash("stop_dodge"), play_idle_animation)
+            -- we are not dodging anymore
+            self.dodge = false
+        end
+    end
+end
+```
+
+### Przykład animacji poklatkowej z węzłem GUI
+
+Przy wyborze obrazu i animacji dla węzła interfejsu graficznego (box, pie) tak naprawdę właśnie przypisujesz źródło obrazów (atlas lub tile source) i domyślną animację, tak samo jak w przypadku sprite'ów. Galeria taka jest statycznie przypisana do węzła, ale animacja może być zmieniona w trakcie trwania programu. Nieruchome obrazki są traktowane jako jednoklatkowa animacja, więc zamiana obrazu jest jednoznaczna z odtworzeniem innej animacji poklatkowej (flip-book) na węźle:
+
+```lua
+local function flipbook_done(self)
+    msg.post("#", "jump_completed")
+end
+
+function init(self)
+    local character_node = gui.get_node("character")
+    -- This requires that the node has a default animation in the same atlas or tile source as
+    -- the new animation/image we're playing.
+    gui.play_flipbook(character_node, "jump_left", flipbook_done)
+end
+```
+
+Jako trzeci argument można podać opcjonalną funkcję, która jest wywoływana w momencie zakończenia animacji (flipbook_done) - to tzw. callback. Będzie ona wywołana po skończeniu animacji, więc tylko takich, które nie są zapętlone, czyli tryby playback: `gui.PLAYBACK_ONCE_*`.
+
+## Przykład animacji szkieletowej Spine
+
+Aby odtworzyć animację na Twoim modelu, po prostu użyj funkcji [`spine.play_anim()`](/ref/spine#spine.play_anim):
+
+```lua
+local function anim_done(self)
+    -- the animation is done, do something useful...
+end
+
+function init(self)
+    -- Play the "walk" animation on component "spinemodel" and blend against previous
+    -- animation for the first 0.1 seconds, then call callback.
+    local anim_props = { blend_duration = 0.1 }
+    spine.play_anim("#spinemodel", "run", go.PLAYBACK_LOOP_FORWARD, anim_props, anim_done)
+end
+```
+
+![Spine model in game](images/animation/spine_ingame.png){srcset="images/animation/[email protected] 2x"}
+
+Jeśli animacja jest odtwarzana w trybach `go.PLAYBACK_ONCE_*` i podałeś funkcję callback w `spine.play_anim()`, funkcja ta zostanie wywołana na końcu animacji. See below for information on callbacks.
+
+### Animacja kursora na modelu Spine
+
+Jako dodatek do `spine.play_anim()` komponenty zwane *Modele Spine* posiadają właściwość zwaną "kursor" (z ang. cursor), którą można animować przy użyciu funkcji `go.animate()`. Jest to wartość numeryczna między 0 i 1, gdzie 0 oznacza początek animacji, a 1 oznacza koniec animacji:
+
+```lua
+-- Set the animation on the spine model but don't run it.
+spine.play_anim("#spinemodel", "run_right", go.PLAYBACK_NONE)
+
+-- Set the cursor to position 0
+go.set("#spinemodel", "cursor", 0)
+
+-- Tween the cursor slowly between 0 and 1 pingpong with in-out quad easing.
+go.animate("#spinemodel", "cursor", go.PLAYBACK_LOOP_PINGPONG, 1, go.EASING_INOUTQUAD, 6)
+```
+
+::: important
+Przy uśrednianiu (tweening) lub ustawianiu kursora, wydarzenia na osi czasu mogą nie być startowane w spodziewanym czasie.
+:::
+
+### Model Spine - hierarchia kości
+
+Indywidualne kości w szkielecie Spine są reprezentowane wewnętrznie przez podstawowe obiekty (game objects). W panelu *Outline* komponentu typu model Spine ukazana jest cała hierarchia. Możesz tu zobaczyć nazwę każdej z kości (bone) i ich miejsce w hierarchii.
+
+![Spine model hierarchy](images/animation/spine_bones.png){srcset="images/animation/[email protected] 2x"}
+
+Znając nazwy poszczególnych kości możesz uzyskać id danej instancji kości w czasie działania programu i dowolnie nią manipulować. Funkcja [`spine.get_go()`](/ref/spine#spine.get_go) zwraca id danej kości a Ty możesz, przykładowo, przypisać inne obiekty jako dzieci danej kości - czyli np. wręczyć postaci pistolet w miejscu ręki, który będzie od tej pory za nią naturalnie "podążał":
+
+```lua
+-- Attach pistol game object to the hand of the heroine
+local hand = spine.get_go("heroine#spinemodel", "front_hand")
+msg.post("pistol", "set_parent", { parent_id = hand })
+```
+
+### Model Spine - wydarzenia na osi czasu
+
+Animacje szkieletowe mogą wywoływać wydarzenia w określonym czasie poprzez wysłanie wiadomości w konkretnym momencie. Jest to bardzo przydatne dla wydarzeń, które powinny być zsynchronizowane z animacją, jak na przykład odtworzenie odgłosu kroku w momencie dotknięcia stopą podłogi (np. gdy stopa jest w najniższym położeniu) czy odtworzenie w tym czasie efektu cząsteczkowego reprezentującego unoszącą się chmurę kurzu. Można w takim wydarzeniu odrzucić lub dołączyć dowolny obiekt do kości czy wywołać jakąkolwiek inną funckję.
+
+Wydarzenia są dodawane w programie Spine i pokazane na osi czasu:
+
+![Spine events](images/animation/spine_events.png)
+
+Każde wydarzenie jest określone przez identyfikator ("bump" w przykładzie powyżej) i może ponadto posiadać dodatkową informację:
+
+Integer
+: Wartość numeryczna całkowita.
+
+Float
+: Wartość numeryczna zmiennoprzecinkowa.
+
+String
+: Wartość słowna, tzw. string.
+
+Kiedy animacja jest odtwarzana i następuje dane wydarzenie to wiadomość o treści `spine_event` jest wysyłana do skryptu, który tę animację uruchomił wywołaniem `spine.play()`. Wiadomość ta posiada tablicę z powyższymi informacjami oraz innymi przydatnymi niejednokrotnie elementami:
+
+`t`
+: Liczba sekund, które upłynęły już od początku animacji.
+
+`animation_id`
+: Shaszowana nazwa (id) animacji.
+
+`string`
+: Opisana wyżej shaszowana wartość słowna.
+
+`float`
+: Opisana wyżej wartość numeryczna zmiennoprzecinkowa.
+
+`integer`
+: Opisana wyżej wartość numeryczna całkowita.
+
+`event_id`
+: Shaszowana nazwa (id) wydarzenia.
+
+`blend_weight`
+: Wartość opisująca jak dużo z animacji jest "zblendowane" w danej chwili. 0 oznacza, że nic z obecnej animacji nie jest jeszcze zblendowane, a 1, że 100% animacji jest już zblendowane.
+
+```lua
+-- Spine animation contains events that are used to play sounds in sync with the animation.
+-- These arrive here as messages.
+function on_message(self, message_id, message, sender)
+  if message_id == hash("spine_event") and message.event_id == hash("play_sound") then
+    -- Play animation sound. The custom event data contains the sound component and the gain.
+    local url = msg.url("sounds")
+    url.fragment = message.string
+    sound.play(url, { gain = message.float })
+  end
+end
+```
+
+## 3D Model animation
+
+Models are animated with the [`model.play_anim()`](/ref/model#model.play_anim) function:
+
+```lua
+function init(self)
+    -- Start the "wiggle" animation back and forth on #model
+    model.play_anim("#model", "wiggle", go.PLAYBACK_LOOP_PINGPONG)
+end
+```
+
+::: important
+Defold wspiera obecnie tylko gotowe animacje (baked). Animacje muszą mieć macierze dla każdej z animowanych kości na każdą z klatek animacji, a nie osobno pozycję, rotację i skalę jako osobne pola. 
+
+Animacje są interpolowane liniowo. Jeśli stworzysz bardziej zaawansowaną krzywą animacji, animacje muszę być przygotowane wcześniej w programie przed eksportem (prebaked).
+
+Klipy animacji (animation clips) w formacie Collada nie są obecnie wspierane. Aby używać wielu animacji na model, wyeksportuj je do osobnego pliku *.dae* i zbierz wszystkie pliki do osobnego pliku *.animationset* w edytorze Defold.
+:::
+
+### Model 3D  - hierarchia szkieletu
+
+Kości szkieletu modelu 3D są reprezentowane wewnętrznie również jako obiekty (game objects).
+
+Możesz uzyskać id danej instancji kości w czasie działania programu i dowolnie nią manipulować. Funkcja [`model.get_go()`](/ref/model#model.get_go) zwraca id obiektu danej kości.
+
+```lua
+-- Get the middle bone go of our wiggler model
+local bone_go = model.get_go("#wiggler", "Bone_002")
+
+-- Now do something useful with the game object...
+```
+
+### Model 3D - animacja kursora
+
+Tak jak powyżej dla komponentów typu Spine, modele 3D mogą być animowane przy użyciu tzw. kursora (ang. `cursor`):
+
+```lua
+-- Set the animation on #model but don't start it
+model.play_anim("#model", "wiggle", go.PLAYBACK_NONE)
+-- Set the cursor to the beginning of the animation
+go.set("#model", "cursor", 0)
+-- Tween the cursor between 0 and 1 pingpong with in-out quad easing.
+go.animate("#model", "cursor", go.PLAYBACK_LOOP_PINGPONG, 1, go.EASING_INOUTQUAD, 3)
+```
+
+## Animowanie właściwości
+
+Aby animować właściwości (ang. properties) obiektu lub komponentu użyj funkcji `go.animate()`. Dla właściwości węzłów GUI, analogiczną funkcją jest `gui.animate()`.
+
+```lua
+-- Set the position property y component to 200
+go.set(".", "position.y", 200)
+-- Then animate it
+go.animate(".", "position.y", go.PLAYBACK_LOOP_PINGPONG, 100, go.EASING_OUTBOUNCE, 2)
+```
+
+Aby zatrzymać wszystkie animacje danej właściwości, wywołaj `go.cancel_animations()`, a dla węzłów GUI, analogicznie: `gui.cancel_animation()` lub dookreśl, które właściwości chcesz zatrzymać:
+
+```lua
+-- Stop euler z rotation animation on the current game object
+go.cancel_animation(".", "euler.z")
+```
+
+Jeśli zatrzymasz animacje właściwości, która jest właściwością "kompozytową" (składającą się z kilku osobnych wartości, jak np. `vector3 position`), osobne animacje każdego z elementów składowych danej właściwości (`position.x`, `position.y` i `position.z`) zostaną zatrzymane.
+
+[Instrukcja do właściwości](/manuals/properties) zawiera wszystkie informacje na temat dostępnych właściwości obiektów, komponentów i węzłów GUI.
+
+## Animowanie właściwości węzłów GUI
+
+Prawie każdą właściwość (ang. property) węzła GUI można animować. Możesz przykładowo ukryć węzeł poprzez ustawienie jego koloru na całkowicie przezroczysty, a następnie pokazać przez płynne pojawianie się animując kolor do wartości koloru białego (nieprzezroczystego):
+
+```lua
+local node = gui.get_node("button")
+local color = gui.get_color(node)
+-- Animate the color to white
+gui.animate(node, gui.PROP_COLOR, vmath.vector4(1, 1, 1, 1), gui.EASING_INOUTQUAD, 0.5)
+-- Animate the outline red color component
+gui.animate(node, "outline.x", 1, gui.EASING_INOUTQUAD, 0.5)
+-- And move to x position 100
+gui.animate(node, hash("position.x"), 100, gui.EASING_INOUTQUAD, 0.5)
+```
+
+## Playback modes - tryby odtwarzania
+
+Animacje w Defoldzie mogą być odtwarzane w różnych trybach - np. jednokrotnie lub w pętli. Jest to określone przez tryby odtwarzania (ang. playback modes):
+
+* go.PLAYBACK_NONE
+* go.PLAYBACK_ONCE_FORWARD
+* go.PLAYBACK_ONCE_BACKWARD
+* go.PLAYBACK_ONCE_PINGPONG
+* go.PLAYBACK_LOOP_FORWARD
+* go.PLAYBACK_LOOP_BACKWARD
+* go.PLAYBACK_LOOP_PINGPONG
+
+Tryb pingpong odtwarza animację raz w poprawnej kolejności, do przodu, a następnie od tyłu. Analogiczne tryby służą do kontroli elementów (węzłów) GUI:
+
+* gui.PLAYBACK_NONE
+* gui.PLAYBACK_ONCE_FORWARD
+* gui.PLAYBACK_ONCE_BACKWARD
+* gui.PLAYBACK_ONCE_PINGPONG
+* gui.PLAYBACK_LOOP_FORWARD
+* gui.PLAYBACK_LOOP_BACKWARD
+* gui.PLAYBACK_LOOP_PINGPONG
+
+## Easing - funkcje wygładzania
+
+Funkcje wygładzania (ang. easing) opisują w jaki sposób animowane wartości zmieniają się w czasie. Obrazy poniżej przedstawiają wykresy funkcji tych wartości w czasie:
+
+Dla animowania wartości obiektów i komponentów przy użyciu `go.animate()`:
+
+|---|---|
+| go.EASING_LINEAR | |
+| go.EASING_INBACK | go.EASING_OUTBACK |
+| go.EASING_INOUTBACK | go.EASING_OUTINBACK |
+| go.EASING_INBOUNCE | go.EASING_OUTBOUNCE |
+| go.EASING_INOUTBOUNCE | go.EASING_OUTINBOUNCE |
+| go.EASING_INELASTIC | go.EASING_OUTELASTIC |
+| go.EASING_INOUTELASTIC | go.EASING_OUTINELASTIC |
+| go.EASING_INSINE | go.EASING_OUTSINE |
+| go.EASING_INOUTSINE | go.EASING_OUTINSINE |
+| go.EASING_INEXPO | go.EASING_OUTEXPO |
+| go.EASING_INOUTEXPO | go.EASING_OUTINEXPO |
+| go.EASING_INCIRC | go.EASING_OUTCIRC |
+| go.EASING_INOUTCIRC | go.EASING_OUTINCIRC |
+| go.EASING_INQUAD | go.EASING_OUTQUAD |
+| go.EASING_INOUTQUAD | go.EASING_OUTINQUAD |
+| go.EASING_INCUBIC | go.EASING_OUTCUBIC |
+| go.EASING_INOUTCUBIC | go.EASING_OUTINCUBIC |
+| go.EASING_INQUART | go.EASING_OUTQUART |
+| go.EASING_INOUTQUART | go.EASING_OUTINQUART |
+| go.EASING_INQUINT | go.EASING_OUTQUINT |
+| go.EASING_INOUTQUINT | go.EASING_OUTINQUINT |
+
+Dla animowania wartości węzłów GUI przy użyciu `gui.animate()`:
+
+|---|---|
+| gui.EASING_LINEAR | |
+| gui.EASING_INBACK | gui.EASING_OUTBACK |
+| gui.EASING_INOUTBACK | gui.EASING_OUTINBACK |
+| gui.EASING_INBOUNCE | gui.EASING_OUTBOUNCE |
+| gui.EASING_INOUTBOUNCE | gui.EASING_OUTINBOUNCE |
+| gui.EASING_INELASTIC | gui.EASING_OUTELASTIC |
+| gui.EASING_INOUTELASTIC | gui.EASING_OUTINELASTIC |
+| gui.EASING_INSINE | gui.EASING_OUTSINE |
+| gui.EASING_INOUTSINE | gui.EASING_OUTINSINE |
+| gui.EASING_INEXPO | gui.EASING_OUTEXPO |
+| gui.EASING_INOUTEXPO | gui.EASING_OUTINEXPO |
+| gui.EASING_INCIRC | gui.EASING_OUTCIRC |
+| gui.EASING_INOUTCIRC | gui.EASING_OUTINCIRC |
+| gui.EASING_INQUAD | gui.EASING_OUTQUAD |
+| gui.EASING_INOUTQUAD | gui.EASING_OUTINQUAD |
+| gui.EASING_INCUBIC | gui.EASING_OUTCUBIC |
+| gui.EASING_INOUTCUBIC | gui.EASING_OUTINCUBIC |
+| gui.EASING_INQUART | gui.EASING_OUTQUART |
+| gui.EASING_INOUTQUART | gui.EASING_OUTINQUART |
+| gui.EASING_INQUINT | gui.EASING_OUTQUINT |
+| gui.EASING_INOUTQUINT | gui.EASING_OUTINQUINT |
+
+![Linear interpolation](images/properties/easing_linear.png){.inline}
+![In back](images/properties/easing_inback.png){.inline}
+![Out back](images/properties/easing_outback.png){.inline}
+![In-out back](images/properties/easing_inoutback.png){.inline}
+![Out-in back](images/properties/easing_outinback.png){.inline}
+![In bounce](images/properties/easing_inbounce.png){.inline}
+![Out bounce](images/properties/easing_outbounce.png){.inline}
+![In-out bounce](images/properties/easing_inoutbounce.png){.inline}
+![Out-in bounce](images/properties/easing_outinbounce.png){.inline}
+![In elastic](images/properties/easing_inelastic.png){.inline}
+![Out elastic](images/properties/easing_outelastic.png){.inline}
+![In-out elastic](images/properties/easing_inoutelastic.png){.inline}
+![Out-in elastic](images/properties/easing_outinelastic.png){.inline}
+![In sine](images/properties/easing_insine.png){.inline}
+![Out sine](images/properties/easing_outsine.png){.inline}
+![In-out sine](images/properties/easing_inoutsine.png){.inline}
+![Out-in sine](images/properties/easing_outinsine.png){.inline}
+![In exponential](images/properties/easing_inexpo.png){.inline}
+![Out exponential](images/properties/easing_outexpo.png){.inline}
+![In-out exponential](images/properties/easing_inoutexpo.png){.inline}
+![Out-in exponential](images/properties/easing_outinexpo.png){.inline}
+![In circlic](images/properties/easing_incirc.png){.inline}
+![Out circlic](images/properties/easing_outcirc.png){.inline}
+![In-out circlic](images/properties/easing_inoutcirc.png){.inline}
+![Out-in circlic](images/properties/easing_outincirc.png){.inline}
+![In quadratic](images/properties/easing_inquad.png){.inline}
+![Out quadratic](images/properties/easing_outquad.png){.inline}
+![In-out quadratic](images/properties/easing_inoutquad.png){.inline}
+![Out-in quadratic](images/properties/easing_outinquad.png){.inline}
+![In cubic](images/properties/easing_incubic.png){.inline}
+![Out cubic](images/properties/easing_outcubic.png){.inline}
+![In-out cubic](images/properties/easing_inoutcubic.png){.inline}
+![Out-in cubic](images/properties/easing_outincubic.png){.inline}
+![In quartic](images/properties/easing_inquart.png){.inline}
+![Out quartic](images/properties/easing_outquart.png){.inline}
+![In-out quartic](images/properties/easing_inoutquart.png){.inline}
+![Out-in quartic](images/properties/easing_outinquart.png){.inline}
+![In quintic](images/properties/easing_inquint.png){.inline}
+![Out quintic](images/properties/easing_outquint.png){.inline}
+![In-out quintic](images/properties/easing_inoutquint.png){.inline}
+![Out-in quintic](images/properties/easing_outinquint.png){.inline}
+
+## Własne funkcje wygładzania
+
+Możesz tworzyć własne funkcje wygładzania zdefiniowane jako specjalny `vector` ze zbiorem odpowiednich, kolejnych wartości i użyć go zamiast predefiniowanych stałych przedstawionych powyżej. Wektor ten reprezentuje krzywą zmiany wartości numerycznej od wartości startowej (`0`) do wartości końcowej (`1`). Silnik interpoluje w czasie działania programu te wartości liniowo.
+
+Na przykład, wektor:
+
+```lua
+local values = { 0, 0.4, 0.2, 0.2, 0.5. 1 }
+local my_easing = vmath.vector(values)
+```
+
+stworzy następującą krzywą:
+
+![Custom curve](images/animation/custom_curve.png)
+
+W poniższym przykładzie wartość y pozycji obiektu skacze między aktualną pozycją startową, a pozycją docelową 200:
+
+```lua
+local values = { 0, 0, 0, 0, 0, 0, 0, 0,
+                 1, 1, 1, 1, 1, 1, 1, 1,
+                 0, 0, 0, 0, 0, 0, 0, 0,
+                 1, 1, 1, 1, 1, 1, 1, 1,
+                 0, 0, 0, 0, 0, 0, 0, 0,
+                 1, 1, 1, 1, 1, 1, 1, 1,
+                 0, 0, 0, 0, 0, 0, 0, 0,
+                 1, 1, 1, 1, 1, 1, 1, 1 }
+local square_easing = vmath.vector(values)
+go.animate("go", "position.y", go.PLAYBACK_LOOP_PINGPONG, 200, square_easing, 2.0)
+```
+
+a krzywa ruchu wygląda jak sygnał prostokątny:
+
+![Square curve](images/animation/square_curve.png)
+
+## Funkcje po zakończeniu animacji - callbacks
+
+Wszystkie funkcje animacji (`go.animate()`, `gui.animate()`, `gui.play_flipbook()`, `gui.play_spine_anim()`, `sprite.play_flipbook()`, `spine.play_anim()` i `model.play_anim()`) przyjmują opcjonalną funkcję zwaną callback jako ostatni argument. Ta funkcja jest wywoływana w momencie zakończenia animacji. Nie jest więc nigdy wywoływana, dla animacji, które są zapętlone, ani w przypadku, gdy animacja jest ręcznie zatrzymana przez funkcje rodzaju `go.cancel_animations()`. Callback może być użyty do uruchomienia wydarzeń, które powinny wystartować w momencie końca animacji, bez wiedzy programisty o czasie jej trwania lub do uruchomienia następnej animacji, zaraz po zakończeniu obecnej.
+
+Dokładna sygnatura funkcji callback różni się nieco dla różnych funkcji animacji (różne argumenty). Sprawdź dokumentację API dla funkcji, którą chcesz użyć.
+
+```lua
+local function done_bouncing(self, url, property)
+    -- We're done animating. Do something...
+end
+
+function init(self)
+    go.animate(".", "position.y", go.PLAYBACK_ONCE_FORWARD, 100, go.EASING_OUTBOUNCE, 2, 0, done_bouncing)
+end
+```

+ 122 - 0
docs/pl/manuals/application-lifecycle.md

@@ -0,0 +1,122 @@
+---
+title: Cykl życia aplikacji w silniku Defold
+brief: Instrukcja opisuje cykl życia aplikacji na silniku Defold i jego szczegóły.
+---
+
+# Cykl życia aplikacji
+
+Cykl życia aplikacji czy gry w silniku Defold jest w ogólności prosty. Silnik przechodzi przez 3 etapy: 
+* inicjalizacja (initialization),
+* aktualizacja w pętli (update loop),
+* finalizacja (finalization).
+
+![Lifecycle overview](images/application_lifecycle/application_lifecycle_overview.png)
+
+W wielu przypadkach nie jest w ogóle wymagana dogłębna wiedza o wewnętrznych procesach silnika Defold. Możesz jednak potrzebować kontrolować lub zbadać pewne skrajne przypadki, wyjątkowe sytuacje, w których potrzebna jest wiedza o kolejności wykonywanych operacji. Dokument ten opisuje jak silnik Defold obsługuje aplikację od początku do końca.
+
+Aplikacja startuje poprzez zainicjalizowanie wszystkiego, co jest potrzebne do pracy silnika. Defold wczytuje główną kolekcję bootstrapową i wywołuje funkcje [`init()`](/ref/go#init) **wszystkich** załadowanych komponentów. Funkcja `init()` może być napisana w języku Lua w skryptach obiektów i GUI, co pozwala na własną inicjalizację.
+
+Aplikacja przechodzi następnie do pętli aktualizacyjnej, która trwa przez większość jej czasu działania, aż do zakończenia programu i przejścia do fazy finalizacyjnej. Każda klatka wyświetlana na ekranie, obiekty i komponenty aplikacji są aktualizowane. Dla każdego skryptu i skryptu GUI specjalna funkcja [`update()`](/ref/go#update) jest wywoływana. Podczas aktualizacji wiadomości są rozsyłane do odbiorców, dźwięki są odtwarzane, a cała grafika jest renderowana i wyświetlana.
+
+W pewnym momencie cykl życia aplikacji dobiega końca. Jeszcze przed tym, zanim aplikacja zamknie się, silnik wyjdzie z pętli aktualizacyjnej i przejdzie do fazy finalizacyjnej. Defold przygotuje wtedy wszystkie załadowane obiekty i kolekcje do usunięcia. Specjalna funkcja [`final()`](/ref/go#final) każdego z komponentów zostanie wywołana, co pozwola na własne procedury finalizacji. Następnie obiekty są usuwane i główna kolekcja jest opuszczana.
+
+## Faza inicjalizacyjna
+
+Diagram poniżej zawiera szczegółowe rozplanowanie kroków inicjalizacji. Kroki we fragmencie rozsyłania wiadomości (ang. "dispatch messages") tuż przed tworzeniem instancji obiektów dynamicznych (ang. "spawn dynamic objects") zostały opisane szczegółowo w osobnym bloku gwoli przejrzystości.
+
+![Lifecycle overview](images/application_lifecycle/application_lifecycle_init.png)
+
+Silnik w zasadzie podejmuje więcej kroków podczas inicjalizacji, jeszcze przed załadowaniem głównej kolekcji. Inicjalizowane są: profiler pamięci (memory profiler), gniazda (sockets), grafika, urządzenia wejścia (HID), dźwięk, fizyka i wiele innych modułów. Plik konfiguracyjny ("game.project") jest wtedy również wczytywany i wykorzystywany.
+
+Pierwszym punktem wejściowym, w którym użytkownik przejmuje kontrolę, już na samym końcu fazy inicjalizacji, jest funkcja `init()` specjalnego skryptu do renderowania (ang. render script).
+
+Główna kolekcja jest następnie załadowywana i inicjalizowana. Wszystkie obiekty (game objects) w tej kolekcji są wtedy tworzone i przypisywana jest im oraz ich dzieciom pozycja, orientacja i skala (całościowo po ang. transform - macierz transformacji). Funkcje `init()` wszystkich załadowanych komponentów są wywoływane, jeśli istnieją.
+
+::: sidenote
+Kolejność w jakiej funkcje `init()` komponentów są wywoływane jest nieokreślona. Nie można zakładać, że silnik zainicjalizuje obiekty zawsze w tej samej kolejności.
+:::
+
+Ponieważ w funkcji `init()` możesz już wysyłać wiadomości, tworzyć nowe obiekty przy użyciu fabryk (factory), przeznaczać obiekty do usunięcia i wiele innych rzeczy, silnik Defold wykonuje zaraz po inicjalizacji jedno przejście "post-update". W przejściu tym rozsyłane są otrzymywane są wysłane wiadomości oraz tworzone i usuwane obiekty. Przejście to zawiera więc również funkcję rozsyłania wiadomości ("dispatch messages"), gdzie nie tylko zakolejkowane wiadomości są wysyłane, ale także obsługiwane są wiadomości do pełnomocników kolekcji (collection proxies). Każda kolejna aktualizacja tych pełnomocników (aktywowanie, dezaktywowanie, wczytywanie i oznaczanie jako gotowe do zwolnienia) są wykonywane w tych krokach.
+
+Analizując diagram powyżej dostrzegamy możliwość załadowania pełnomocnika kolekcji [(collection proxy)](/manuals/collection-proxy) w funckji `init()`, zainicjalizowania jej obiektów, a następnie zwolnienia kolekcji - wszystko to jeszcze przed pierwszym wywołaniem funkcji `update()` pierwszego komponentu, czyli przed wyjściem z fazy inicjalizacyjnej do pętli aktualizacyjnej:
+
+```lua
+function init(self)
+    print("init()")
+    msg.post("#collectionproxy", "load")
+end
+
+function update(self, dt)
+    -- The proxy collection is unloaded before this code is reached.
+    print("update()")
+end
+
+function on_message(self, message_id, message, sender)
+    if message_id == hash("proxy_loaded") then
+        print("proxy_loaded. Init, enable and then unload.")
+        msg.post("#collectionproxy", "init")
+        msg.post("#collectionproxy", "enable")
+        msg.post("#collectionproxy", "unload")
+        -- The proxy collection objects’ init() and final() functions
+        -- are called before we reach this object’s update()
+    end
+end
+```
+
+## Faza aktualizacyjna - pętla
+
+Pętla aktualizacyjna (update loop) przez cały czas trwania aplikacji jest wykonywana w każdej klatce. Sekwencja aktualizacji przedstawiona na diagramie poniżej jest podzielona na logiczne sekcje gwoli przejrzystości. Rozsyłanie wiadomości (ang. "dispatch messages") jest ponadto dodatkowo podzielona z tego samego powodu:
+
+![Update loop](images/application_lifecycle/application_lifecycle_update.png)
+
+## Wejścia
+
+Wejścia są odczytywane ze wspieranego urządzenia, na którym działa aplikacja i mapowane zgodnie z zasadami umieszczonymi w opisie wiązania wejść [(ang. input bindings)](/manuals/input), a następnie rozsyłane. Każdy obiekt (game object), który zadeklarował przechwytywanie wejść (ang. acquired input focus) otrzymuje wejścia wysłane do funkcji `on_input()` jego wszystkich komponentów, w tym oczywiście skryptów i skryptów GUI komponentów GUI. Jeśli obiekt posiada oba, do wszystkich zostaną wysłane wejścia, zakładając oczywiście, że zadeklarowały przechwytywanie wejść.
+
+Każdy obiekt, który zadeklarował przechwytywanie wejść i posiada jednego lub więcej pełnomocników kolekcji przesyła wejścia do komponentów wewnątrz tych pełnomocników. Proces ten działa rekursywnie dla każdych obiektów wewnątrz aktywnych pełnomocników, itd.
+
+## Aktualizacja komponentów
+
+Silnik przechodzi przez każdy obiekt w głównej kolekcji i jeśli którykolwiek z komponentów posiada funkcję `update()` będzie ona wywołana. Jeśli komponentem jest pełnomocnik kolekcji, każdy komponent takiego pełnomocnika jest sprawdzany rekursywnie w dół i aktualizowany zgodnie z wszystkimi krokami opisanymi powyżej.
+
+::: sidenote
+Kolejność w jakiej funkcje `update()` komponentów są wywoływane jest nieokreślona. Nie można zakładać, że silnik zaktualizuje obiekty zawsze w tej samej kolejności.
+:::
+
+W następnej kolejności wszystkie wiadomości są rozsyłane. A ponieważ każdy z komponentów, który otrzymuje wiadomość, w funkcji `on_message()` może wysyłać dodatkowo następne wiadomości, więc ten sam mechanizm rozsyłania wiadomości (ang. message dispatcher) działa dopóki kolejka wiadomości nie zostanie opróżniona. Istnieje jednak limit takich iteracji przejścia przez kolejkę wiadomości. Szczegóły znajdziesz w opisie [przesyłania wiadomości](/manuals/message-passing) w sekcji "Zaawansowane" (ang. "Advanced topics").
+
+Jeśli chodzi o wiadomości do obiektów kolizji (ang. collision object) i wiadomości dotyczących silnika fizycznego (odpowiedzi kolizji, przełączników (ang. triggers), promieni (ang. ray_cast), itp.) są one rozsyłane podczas obsługi każdego z obiektów do wszystkich komponentów, które posiadają funkcję `on_message()`.
+
+Macierze transformacji (ang. transforms) są później tworzone i aplikowane do obiektów, ich komponentów i kolejnych obiektów-dzieci- zmieniana jest ich pozycja, orientacja i skala.
+
+## Aktualizacja renderowania
+
+Sekcja aktualizacji renderowania rozsyła i obsługuje wiadomości przesłane do specjalnego gniazda (ang. socket) `@render` (np. wiadomości `set_view_projection` dla kamery, ustawianie koloru czyszczenia ekranu `set_clear_color`, itp.). Następnie wywoływana jest funkcja `update()` skryptu renderowania (ang. render script).
+
+## Post-aktualizacja
+
+Po aktualizacji uruchamiana jest sekwencja tzw. post-aktualizacji. Zwalnia ona z pamięci pełnomocników kolekcji, którzy zostali do takiego zwolnienia oznaczeni (zdezaktywowani podczas rozsyłania wiadomości - sekwencji "dispatch messages"). Każdy obiekt, który jest przeznaczony do usunięcia wywołuje funkcję `final()` we wszystkich komponentach, jeśli istnieje. Kod w funkcji `final()` może również wysyłać wiadomości, więc dodatkowe przejście przez kolejkę wiadomości jest uruchamiane na końcu.
+
+Każdy komponent typu fabryka (ang. factory), który został oznaczony jako gotowy do utworzenia obiektu, w tym momencie utworzy taki obiekt. Na końcu obiekty, które są przeznaczone do usunięcia zostają usunięte.
+
+Ostatnim krokiem pętli aktualizacyjnej jest obsługa wiadomości kolejnego, specjalnego gniazda `@system` (wiadomości `exit`, `reboot`, przełączanie profilera, startowanie i zatrzymywanie przechwytywania video, itp.). Następnie renderowana jest grafika. Podczas renderowania grafiki, tworzone jest przychwytywanie video, tak samo jak i wizualizacja profilera (zobacz [dokumentację do debugowania](/manuals/debugging).)
+
+## Klatki na sekundę i krok czasowy kolekcji
+
+Liczba klatek na sekundę (równa liczbie pętli aktualizacyjnych na sekundę) może być ustawiona w pliku konfiguracyjnym projektu (`game.project`) lub dynamicznie przez wysłanie wiadomości `set_update_frequency` do specjalnego gniazda `@system`. Dodatkowo, możliwe jest ustawienie kroku czasowego (ang. _time step_) dla pełnomocników kolekcji indywidualnie poprzez wysłanie wiadomości `set_time_step`. Zmiana czasu kroku kolekcji nie wpływa na liczbę klatek na sekundę - jedynie na aktualizację fizyki oraz wartość `dt` przekazywaną do funkcji `update().` Zauważ również, że zmiana kroku czasowego nie zmienia samej liczby wywołań funkcji `update()`, które są wywoływane w każdej klatce - a ta nie ulega zmianie.
+
+(Szczegóły znajdziesz w [Instrukcji do pełnomocników kolekcji](/manuals/collection-proxy) i [`set_time_step`](/ref/collectionproxy#set-time-step))
+
+## Faza finalizacyjna
+
+Kiedy aplikacja jest zamykana, najpierw kończona jest ostatnia pętla aktualizacyjna, która zwolni wszystkich pełnomocników kolekcji: finalizując i usuwając wszystkie obiekty w każdym z nich.
+
+Kiedy to się zakończy silnik przejdzie do sekwencji finalizacyjnej, która zamknie główną kolekcję i jej obiekty:
+
+![Finalization](images/application_lifecycle/application_lifecycle_final.png)
+
+Funkcje `final()` wszystkich komponentów zostaną najpierw wywołane. Jeśli w kodzie tych funkcji wysyłane są jeszcze jakieś wiadomości, zostaną one wysłane i obsłużone. Ostatecznie, wszystkie obiekty zostaną usunięte i główna kolekcja zostanie zwolniona.
+
+Silnik będzie kontynuował jeszcze finalizację i zwalnianie elementów wewnętrznych, takich jak: konfiguracja projektu, profiler pamięci, itd.
+
+Aplikacja jest na końcu zamknięta.

+ 112 - 0
docs/pl/manuals/building-blocks.md

@@ -0,0 +1,112 @@
+---
+title: Podstawowe elementy silnika Defold
+brief: Instrukcja ta przedstawia podstawowe elementy służące do budowania aplikacji w Defoldzie oraz opisuje jak działają obiekty, komponenty i kolekcje.
+---
+
+#  Podstawowe elementy do budowania aplikacji
+
+W samym sercu koncepcji silnika Defold znajduje się kilka elementów, których zrozumienie ułatwia dalszą pracę z silnikiem. Instrukcja ta wyjaśnia czym są takie bloki służące do budowania aplikacji. Po zapoznaniu się z poniższą instrukcją, warto przejść do [Instrukcji adresowania](/manuals/addressing) i [przesyłania wiadomości](/manuals/message-passing). Na stronie Defold znajdziesz również [tutoriale](/tutorials/getting-started) dla początkujących dostępne nawet z poziomu edytora, aby umożliwić Ci szybki start z silnikiem Defold.
+
+![Building blocks](images/building_blocks/building_blocks.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Przy budowaniu gier na silniku Defold używa się trzech podstawowych elementów:
+
+Kolekcja (Collection)
+: Kolekcja jest plikiem używanym do stworzenia struktury Twojej gry. W kolekcjach buduje się hierarchię obiektów gry (poniżej) i innych kolekcji. Kolekcja jest więc po prostu zbiorem obiektów i innych kolekcji. Zazwyczaj używa się ich do stworzenia struktury całych poziomów w grach czy też grup wrogów, postaci, pocisków czy innych elementów (wielu obiektów).
+
+Obiekt gry (Game object)
+: Obiekty gry są pojemnikami zawierającymi identyfikator (id), pozycję, orientację i skalę oraz mogą zawierać dodatkowo tzw. komponenty (poniżej). Są używane zazwyczaj do tworzenia postaci gracza, innych pojedynczych elementów, lub systemów tworzenia zasad gry oraz jako elementy wczytujące i zwalniające dane poziomy.
+
+Komponent (Component)
+: Komponenty to elementy, które są umieszczane wewnątrz obiektów, aby nadać im cechy zgodne z ich typem - reprezentację wizualną (sprite, model, particlefx), dźwiękową (sound) czy logiczną (script). Są zazwyczaj używane do stworzenia sprite'ów czy modeli postaci, dodawania skryptów do obiektów czy efektów dźwiękowych czy cząsteczkowych.
+
+## Kolekcje
+
+Kolekcje mają strukturę drzewa, która przechowuje obiekty i inne kolekcje. Kolekcje są zawsze przechowywane w formie pliku.
+
+Kiedy Defold startuje, wczytuje pojedynczą, główną _kolekcję bootrstrapową_ określoną w pliku "game.project". Kolekcja bootstrapowa jest często nazywana "main.collection" (i tak jest też domyślnie nazwana po otwarciu każdego nowego projektu), ale oczywiście możesz używać dowolnej nazwy.
+
+Kolekcja może zawierać obiekty i inne kolekcje (przez referencję do pliku sub-kolekcji) zagnieżdżone na dowolną "głębokość". Poniżej jest przykład kolekcji "main.collection". Zawiera ona jeden obiekt gry (z id "can")i jedną sub-kolekcję (z id "bean"). Sub-kolekcja ta zawiera z kolei obiekty "bean" i "shield".
+
+![Collection](images/building_blocks/collection.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Zauważ, że sub-kolekcja z id "bean" jest przechowywana w osobnym pliku nazwanym "/main/bean.collection", a kolekcja nadrzędna "main.collection" zawiera do tego pliku jedynie referencję:
+
+![Bean collection](images/building_blocks/bean_collection.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Nie można zaadresować kolekcji samej w sobie, ponieważ nie istnieją obiekty w czasie rzeczywistym, które reprezentują kolekcje "main" czy "bean" - nie można więc wysłać wiadomości do kolekcji samej w sobie, a tylko do obiektów i komponentów. Jednak czasem chcesz wysłać wiadomość do obiektu z innej kolekcji niż kolekcja, w której nadawca się znajduje, więc dlatego określą się ścieżkę (ang. _path_) do takiego obiektu z uwzględnieniem id kolekcji (Szczegóły znajdziesz w [Instrukcji adresowania](/manuals/addressing)):
+
+```lua
+-- file: can.script
+-- get position of the "bean" game object in the "bean" collection
+local pos = go.get_position("bean/bean")
+```
+
+Kolekcja dodawana do innej kolekcji jest zawsze referencją do _pliku_ kolekcji:
+
+Naciśnij <kbd>Prawy-przycisk-myszki</kbd> na kolekcji w panelu *Outline* i wybierz <kbd>Add Collection File</kbd>.
+
+## Obiekty gry
+
+Obiekty gry to bardzo proste obiekty posiadające indywidualny czas życia w trakcie wykonywania programu. Posiadają pozycję, orientację i skalę, a parametry te mogą być manipulowane i animowane osobno w czasie działania programu.
+
+```lua
+-- animate X position of "can" game object
+go.animate("can", "position.x", go.PLAYBACK_LOOP_PINGPONG, 100, go.EASING_LINEAR, 1.0)
+```
+
+Obiekty gry mogą być używane jako puste obiekty (jako znacznik pozycji (ang. waypoint, startpoint, checkpoint etc.)), ale najczęściej zawierają komponenty, takie jak sprite'y, dźwięki, skrypty, modele, fabryki, efekty cząsteczkowe i inne. Obiekty te są tworzone albo z poziomu edytora i umieszczane bezpośrednio w plikach kolekcji (statycznie) albo dynamicznie, w kodzie, dzięki fabrykom (ang. _factory_).
+
+Obiekty gry są więc dodawane jako nowe obiekty zdefiniowane w pliku kolekcji lub również w pliku kolekcji, ale jako referencja do osobnego pliku z definicją obiektu gry:
+
+Naciśnij <kbd>Prawy-przycisk-myszki</kbd> na kolekcji w panelu *Outline* i wybierz <kbd>Add Game Object</kbd> (dodasz definicję do kolekcji) or <kbd>Add Game Object File</kbd> (dodasz do kolekcji referencję do pliku z definicją obiektu).
+
+Jest to jeszcze dogłębniej wytłumaczone poniżej.
+
+
+## Komponenty
+
+:[components](../shared/components.md)
+
+Odsyłamy do osobnej [Instrukcji do komponentów](/manuals/components/), gdzie znajduje się lista wszystkich komponentów silnika Defold.
+
+## Obiekty dodawane bezpośrednio i z pliku
+
+Kiedy tworzysz _plik_ kolekcji, obiektu gry lub nawet komponentu (np. w panelu *Assets*), tak naprawdę tworzysz tylko szablon, prototyp (ang. blueprint, prototype). Tworzy to tylko i wyłącznie plik w strukturze Twojego projektu, natomiast nic nie jest dodawane do samej gry. Aby stworzyć _instancję_ kolekcji, obiektu czy komponentu do gry, która bazuje na takim pliku-szablonie, dodać należy taką instancję w jednej z Twoich kolekcji.
+
+W panelu *Outline* możesz zobaczyć na jakim pliku bazuje dana instancja, jeśli była ona stworzona z pliku, a nie bezpośrednio w panelu *Outline* właśnie. Przykładowo, kolekcja "main.collection"  poniżej zawiera trzy instancje, które bazują na już utworzonych plikach:
+
+1. Sub-kolekcja "bean".
+2. Komponent typu skrypt "bean" w obiekcie "bean"  w sub-kolekcji "bean".
+3. Komponent typu skrypt "can" w obiekcie "can".
+
+![Instance](images/building_blocks/instance.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Korzyścią z używania szablonów/plików jest zdecydowanie możliwość stworzenia wielu instancji obiektu gry lub kolekcji i zmiana ich wszystkich naraz w jednym pliku:
+
+![GO instances](images/building_blocks/go_instance.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Przy zmianie pliku każda instancja utworzona z tego pliku zostaje natychmiastowo zaktualizowana:
+
+![GO instances updated](images/building_blocks/go_instance2.png){srcset="images/building_blocks/[email protected] 2x"}
+
+## Hierarchia obiektów gry - relacja rodzic-dziecko
+
+W pliku kolekcji możesz tworzyć hierarchie obiektów gry (game objects) w ten sposób, że jeden z obiektów jest dzieckiem innego obiektu - rodzica. Po prostu <kbd>przeciągnij</kbd> jeden z obiektów gry i <kbd>upuść</kbd> nad innym obiektem - zostanie on umieszczony w drzewku pod tym obiektem i stanie się jego dzieckiem:
+
+![Childing game objects](images/building_blocks/childing.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Relacja rodzic-dziecko jest dynamiczną relacją wpływającą na zmianę pozycji, orientacji i skali obu obiektów. Każda transformacja tych wartości zaaplikowana do obiektu rodzica zostanie następnie zaaplikowana do obiektu dziecka, aby ich wzajemna, względna pozycja/orientacja/skala pozostała taka sama, 1:1, zarówno w edytorze jak i w czasie działania programu:
+
+![Child transform](images/building_blocks/child_transform.png){srcset="images/building_blocks/[email protected] 2x"}
+
+Z kolei wszystkie transformacje na obiekcie dziecku są wykonywane w układzie odniesienia rodzica. W edytorze Defold możesz wybrać, czy operacje na obiekcie dziecku są wykonywane w układzie lokalnym rodzica (local space) czy w głównym układzie odniesienia (world space) klikając <kbd>Edit ▸ World Space</kbd> (domyślnie ustawione) lub <kbd>Edit ▸ Local Space</kbd>.
+
+Jest też możliwe zmienienie rodzica danego obiektu przez wysłanie do niego wiadomości `set_parent`.
+
+```lua
+local parent = go.get_id("bean")
+msg.post("child_bean", "set_parent", { parent_id = parent })
+```
+
+Częstym błędem jest postrzeganie przypisania obiektu jako dziecka innego obiektu w kolekcji jako zmiana miejsca tego obiektu w hierarchii kolekcji. Są to jednak dwie osobne rzeczy. Relacje rodzic-dziecko dynamicznie zmieniają graf w panelu *Outline*, co pozwala wizualnie ją przedstawić. Jedyną rzeczą, która określa adres obiektu jest jej miejsce w hierarchii kolekcji. Adres jest statyczny podczas całego cyklu życia obiektu.

+ 36 - 0
docs/pl/manuals/introduction.md

@@ -0,0 +1,36 @@
+---
+title: Defold - Wprowadzenie
+brief: Krótki wstęp do Defolda
+---
+
+# Witamy w Defoldzie!
+
+Defold jest platformą przeznaczoną do profesjonalnej produkcji gier, ułatwiającą grupom deweloperów projektować, budować i _przygotowywać_ gry na wspierane platformy. Defold skupia się na stworzeniu ogólnego środowiska, oddając Ci w ręce wszystkie podstawowe elementy, bez wprowadzania zbędnych, skomplikowanych komponentów. Wierzymy, że siłą Defolda jest danie użytkownikom zestawu prostych, ale potężnych narzędzi, które umożliwiają wspólną pracę nad grą. Oznacza to, że czasami będziesz wykonywać dodatkową pracę, aby stworzyć komponent dopasowany do Twoich potrzeb, ale daje Ci to całkowitą nad tym kontrolę, a sama droga do Twojego celu jest bardziej przejrzysta i zrozumiała dla Ciebie.
+
+Jeśli jesteś początkującym albo doświadczonym deweloperem, może zająć chwilę, zanim załapiesz pewne koncepty. Zachęcamy do eksperymentowania i podążania za tutorialami, czytania instrukcji i dokumentacji API oraz do aktywności na naszym forum, gdzie użytkownicy i twórcy silnika pomogą Ci z każdym zagadnieniem dotyczącym silnika. Defold jest rozwijany nieustannie i co miesiąc wypuszczana jest nowa wersja, która jest kompatybilna wstecznie, więc aktualizacja nie powinna powodować błędów w Twoim obecnym projekcie.
+
+## Gdzie rozpocząć?
+
+Na stronach Defolda znajdziesz mnóstwo dokumentacji, instrukcji, przykładów i tutoriali. Jeśli nie wiesz od czego zacząć, poniżej przedstawiamy szybki wstęp:
+
+#### Edytor Defold
+![Editor overview](images/introduction/editor.png){.left} [Instrukcja do edytora Defold](/manuals/editor/) opisuje edytor i pozwala Ci szybko zacząć swobodne poruszanie się w środowisku, używać narzędzi wizualnych i pisać kod. Jeśli jesteś zaznajomiony z innymi IDE lub programami do modelowania 3D część rzeczy może Cię zaskoczyć, ale zazwyczaj jest tak właśnie, że wygląd i funkcje różnią się między programami.
+
+#### Proste przykłady
+![Examples](images/introduction/examples.jpg){.left} [Nasz zestaw prostych przykładów](/examples/) to dobre miejsce na start i zrozumienie jak składać małe elementy razem w coś, co działa. Znajdziesz tam funkcje i operacje w Defoldzie w minimaljnej formie.
+
+#### Język Lua
+![Lua overview](images/introduction/lua.png){.left} [Defold wykorzystuje język Lua](/manuals/lua/) do tworzenia logiki gry. Silnik jest natomiast napisany w języku C++ i zoptymalizowany do szybkiego wykonywania zadań. Jeśli programowałeś już w Pythonie, Javascripcie lub innym wysoko poziomowym języku, Lua powinna być dla Ciebie prosta do zrozumienia i nauczenia się i bez problemu powinieneś móc przejść do tutoriali dotyczących bezpośrednio Defolda. W innym przypadku, warto najpierw przeczytać instrukcję języka Lua.
+
+#### Tutoriale gier
+![Tutorials](images/introduction/tutorials.jpg){.left} Wierzymy, że najlepiej uczy się przez tworzenie. Przygotowaliśmy więc zbiór tutoriali na różnych poziomach zaawansowania, dostępnych bezpośrednio z poziomu [edytora](/manuals/editor/). Uruchom je i podążaj za instrukcjami, aby szybko nauczyć się jak budować rzeczy i jak działa Defold.
+
+#### Podstawowe elementy
+![Building blocks](images/introduction/building_blocks.png){.left} [Defold wykorzystuje kilka podstawowych elementów do budowania aplikacji](/manuals/building-blocks/), niektóre z nich mogą Ci się wydać już znajome lub analogiczne do elementów z innych silników. Jest kilka decyzji związanych z architekturą silnika Defold, które sprawiają, że te elementy mają specyficzny charakter, więc może zająć chwilę, aby czuć się z nimi komfortowo i używać ich w naturalny sposób. Służy to jednak zoptymalizowaniu tworzenia gier na silniku Defold. Nasza instrukcja dotycząca tych bloków to dobre miejsce, aby zacząć rozumieć koncepty Defolda i dowiedzieć się jak to dokładnie działa.
+
+#### Forum
+![Forum](images/introduction/forum.jpg){.left} [Uczenie się od innych użytkowników](//forum.defold.com/) jest również często najlepszym sposobem na naukę. Nasza społeczność jest bardzo przyjazna, otwarta i wie dużo na temat tworzenia gier w ogólności, a także w szczególności na silniku Defold. Jeśli kiedykolwiek utkniesz, nie wahaj się, aby zapytać o rozwiązanie Twojego problemu na forum. (Będziesz musiał kontaktować się w języku angielskim, ale na forum, discordzie czy slacku możesz znaleźć kogoś, kto zna język polski w razie problemów - przyp. tłumacza)
+
+Pamiętaj, że niezależnie od Twojego podejścia do nauki Defolda możesz zawsze wrócić tutaj i wyszukać na stronie szczegóły dotyczące różnych operacji i konceptów. Nie wahaj się wskazywać rzeczy, któych nie jesteś w stanie zrozumieć lub uważasz, że nie są prawidłowe. Wszystkie te instrukcje są dla Ciebie i będziemy pracować nad tym, żeby dopasować je do Twoich potrzeb.
+
+Mamy nadzieję, że będziesz się cieszyć tworząc Twoją wymarzoną grę w Defoldzie!