Odin Inspector and Serializer | Improve your workflow in Unity
https://odininspector.com/

Nutno rict, ze tohle jsou extremne dobre investovane penize - vrele doporucuju, opravdu extremne sikovna vec, ktera resi unit problemy se serializaci a umoznuje docela hezky a rychle modifikovat inspektory.

Primitivni "skriptovaci" jazyk na klikani pro designera jsem diky tomu udelal za chvilicku, misto abych se s tim prcal ve snaze obchazet unity serializaci :)

Na druhou stranu už začínám chápat to Unity of Love and Hate. Garry Newman, ten co dělá Rust hezky shrnul, co ho naopak na Unity sere:
What Unity Is Getting Wrong - Garry's Blog
https://garry.tv/unity-2020

SHIGORBIRDMAN: Pár víkendů jsem si s tím teď hrál a jo, jsou tam problémy. Velmi málo dokumentace nebo prostě odpovědí na problémy, ke kterým se dostanu, různý věci se tam mění, takže návody, který už někdo udělal nefungují úplně přesně, protože něco přejmenovali, nebo dělají trošku jinak.
Ale je pak krásný vidět, co to umí v akci. Okamžitý instancování desetitisíců objektů, subscény, přes který si víceméně můžeš vytvořit open world.

JAACOB: tak tohle je spis syntakticky cukr nad unsafe kontextem a praci s pointrama ;)
dots afaik funguje prece jen trochu jinak, ale furt jsem se nedostal k tomu, abych si s nim zacal nejak hrat... a nejspis pockam, az se to v unity jeste trochu vyvine, co jsem slysel, zatim je ta implementace prilis mlada a menena...


SLASH: teoreticky muzes stejne veci delat v unity od zacatku, ale prace s unsafe a pointery je kapku otravna a nebezpecna... driv jsem to u par veci delal, protoze v cistem c# se to proste nehlo, kdyz jsem pracoval s polem misto pointery

btw celkem podobne jako ten Span funguje v Unity NativeSlice (Unity.Collections package)

SLASH: jen jsem to prolitl, ale mam za to, ze na stejnem principu je prave postavenej celej DOTS (ne teda na tom Spanu, ale na podobne organizaci dat). Je to pristup, kde prave ty linearni alokace jsou zaklad uspechu - ulehcuji pristup k datum a umoznujou multitasking. Akorat bude asi sichta se odpoutat od zaziteho OOP a zacit u architektury premyslet jinak...

https://www.stevejgordon.co.uk/an-introduction-to-optimising-code-using-span-t

zatial to nefunguje v Unity, ale dobry sposob zrychlenia / optimalizacie kodu...

JAACOB: jj, dalsi dobry tip... takze odpoved bolo vypnutie recyklacie tweenow! v tom
DOTween.Init stacilo zmenit prvy parameter na true a vsetky moje problemy z tweens sa poriesili!
blody hell, tolko casu som s tym zabil :(

SLASH: Zvlastni - na prvni pohled v tom kodu nevidim problem. Jeste me napada, jestli to nemuze byt nejaky bordel s recyklaci tweenu - vim, ze s tim jeden kolega kdysi zapasil a konfiguroval jinak appku. Zkus mrknout na dokumentaci initu a zkus upravit parametry a pouzit ten safe mode nebo vypnout recyklaci - jestli problem nahodou neni tam..?
DOTween - Documentation
http://dotween.demigiant.com/documentation.php?api=DOTween.Init

PATRIKSIMA: Spravne je to tak, ze kdyz hrac nema stisknuty input strelby, tak proste cekas, az stisknutej bude. Jakmile se detekuje, ze jako jo, tak vystrelis a ulozis si nejakej TimeoutDoDalsihoVystrelu - coz je realne cas podle kadence zbrane. Pak v kazdem updatu, pokud je TimeoutDoDalsihoVystrelu > 0, tak od nej odectes time.deltaTime (cas framu). Az v okamziku, kdy je <= 0, tak muzes vystrelit znovu. Ale nenastavis ho znova na celou hodnotu, jen k aktualni hodnote tu novou prictes. Takze kdyz po odectu byla hodnota zaporna, tak to je "kompenzace" za to, zes mel vystrelit uz tech par milisekund zpet. Chtel jsem poslat link na unity, ale to je zmatene a jeste blbe... :)
Kod by mel vypadat napr. takhle nejak:

private float fireDelta = 100f; // kadence
private float timeToShoot = 0f; // timeout do dalsiho vystrelu

private void Update()
{
    if (timeToShoot > 0) timeToShoot -= time.deltaTime;

    if (Input.GetButton("Fire1") && timeToShoot <=0)
    {
       Shoot(); // spawn projektilu, animace - whatever
       timeTiShoot += fireDelta; // proste deltu prictem, neresetujem! Takze ten zaporny cas, o ktery jsme prisli delkou framu mame kompenzovany...
    }

    if (timeToShoot < 0) timeToShoot = 0; // ale aby se "nenabijel" firerate kdyz nestrilis nebo neco, tak tady cas resetujem na 0...
}

JAACOB: Est raz diki za rady, prepisal som to tak ze je tam pouzita ta coroutine a seqvencia : https://pastebin.com/3FcwatHx

funguje to celkom dobre, ale teraz tam vznikol taky bug...

Pokial sa pouzije funkcionality Hint (cize to tlacitko vpravo dole, ktore ukaze uzivatelovy ktory objekt ma najst) a toto zavola na Hunt.cs funkciu showHintAnimation() co je v podstate taky jednoduchy yoyo color tween, a potom user klikne na ten objekt a spusti showFoundAnimation().. ten posledny fade tween sa nevykona, tym padom sa ani OnComplete nevykona ktore by malo znicit ten gameObject takze ostane ta minca visiet na scene .. a uz samozrejme nie je klikatelna. Nestava sa to ale vzdy, niekedy to funguje OK aj napriek tomu ze je minca kliknuta pocas tej hint animacie.

Napadlo ma dat tam timeline insert s callbackom na znicenie objektu, namiesto zavesit no na OnComplete?
Alebo co by si navrhol za riesenie?

Tu je preview, stalo sa to hned na zaciatku..
hunt
http://www.youtube.com/watch?v=UlRHYyr-MAs

K tomu jak se jednoduse da udelat slusnej fuckup v timingu tu mam jednu perlicku z praxe - v byvale praci pri hrani nasi strilecky jsem proste citil, ze FPS ovlivnuje rychlost strelby zbrane. Zacal jsem se vrtat v kodu a zjistil, ze je to napsane uplne blbe. Mezi vystrelama se cekalo na timeout podle kadence zbrane, vystrelilo se a pak se cekalo zase stejnej timeout. To je ale blbe. Zkusim nacrtnout:

╚══════╝ Pozadovany realny interval mezi vystrely

Realny framerate (N = nevystrel, V = vystrel)
N────N────N────N────N

Optimalni chovani strelby - v kazdem framu vyhodnocujes, jestli od presneho casu posledniho vystrelu uz muzes strilet znova:

V────N────V────V────N────V────V────V─...
╚══════╩══════╩══════╩══════╩══════╩═...

Situace, kde kontrolujes, jestli uz muzes v danem framu vystrelit a kdyz jo, tak restartujes timeout:

V────N────V────N────V────N────V────N...
╚══════╝    ╚══════╝    ╚══════╝    ╚═════...

To je ale blbe! (a takhle podle me funguje i ten InvokeRepeating). Tady je videt, ze i na 8 framech s vysokou kadenci jsi schopnej u spatneho pristupu okrast hrace o 2 vystrely...to je velkej pruser! :)
TOBE by se pak klidne mohlo stat, ze ti podle FPS ty invoke-repeating/frame count fajrovani eventu muze klidne vychazet uplne na random o +- pul vteriny, takze se jednou ten fade zvladne, jindy ne...

SLASH: dej spis pak vedet jak jsi dopadl. Jestli pomohl ten unbind kliku nebo aspon ten prepis na sekvenci. Osobne si myslim, zes tam mel primarne spis rozkople casovani a zalezelo na tom, jak ti zrovna vysly ty invoky. Nevim totiz kdo presne a kdy vlastne vola ten destroy. Ale jestli je to neco, co je hookle na tu tvoji Action onItemClicked, tak by to tu akci melo zavolat v optimalnim svete, kde frametime je nekonecne maly za 0.375 vteriny - prakticky o polovinu driv, nez se nejaky fade vubec zacne resit. Realne to ale bude treba i 2x delsi cas asi.

Uprimne nejsem expert na realne fungovani InvokeRepeating, ale dal bych si na nej velkeho majzla hned z nekolika duvodu. Jednak je prasarna spoustet metody jejich string nazvem. Uz kvuli tomu je jasne, ze tam bude figurovat nejaka hnusna a uplne zbytecne narocna reflexe. Za druhe - kdyz budes nekde ve VS dohledavat reference, dostanes leda prd, protoze se na tu metodu technicky nikdo neodkazuje. Co vede k dalsimu problemu - lehce kvuli chybe muzes nekde zapomenout invoke vypnout (nebo se upsat v nazvu metody) a zadelavas si na problem. Refactoring rename je taky v prdeli - na Invoky se zapomene. A nakonec - a to je fakt jen muj dohad - ale rekl bych, ze kdyz das invoke repeating na tak malej interval, tak ze on proste jenom bude cekat na timeout, pak zavola metodu a pak nastavi zase uplne stejnej timeout. Jenomze kdyz nebudes pocitat "preteceni" delky framu (coz si myslim, ze InvokeRepeating resit nebude), tak se ti proste na zaklade FPS budou brutalne lisit doby, za ktere to tech 50 timeoutlych ticku udela.

Navic jeste - kdyz mas neco timeoutovane v tak malych casoych dimenzich, je to FPS bound a bude se mega lisit timing tech tweenu a volani callbacku. Dovysvetlim:

Pokud ti hra renderuje v 60FPS, mel bys mit time.deltatime mezi framama nejakych 16.6ms, kdyz hra jede 30FPS, tak je deltatime cca 33ms. Rozdil u 50 framu je dvojnasobny cas. Proto bys nemel pocitat framy, ale absolutni cas, kdy neco naplanujes, protoze v prvnim pripade to bude trvat 25*16ms = 0.4s, v druhem pripade 25*33ms = 0.82 sekundy...

SLASH: fju to je teda divokej zapis! Pri kliku startujes dva solo tweeny, dalsi rizeni pres invoke repeating, trocha casovani, trocha pricitani...jako bonus nevim co je BetterImage a jestli do toho nemuze nejak vrtat anebo jestli treba nahodou tyhle objekdy nejak neprepouzivas / necachujes (doufam teda, ze ne).

Par veci:
- nemas zabezpeceny, ze kdyz na item kliknes jednou, tak ze uz nekliknes podruhe (jestli to ma byt nejaka "finalize" animace, tak v tom minimalne odregistruj click handler, nebo checkni, jestli uz neanimujes nahodou a dalsi klik zahod.

- u tweenu - kdyz kombinujes nekolik efektu v poradi, pouzivej radeji DOTween.Sequence(), kde nahazes nekolik tweenu za sebou pomoci .Append() anebo na libovolne misto pomoci .Insert(). Jako bonus - kdyz z bezpecnostnich duvodu tweeny treba v Destroy killujes nebo dokoncujes, budes resit jen jednu sekvenci, ne pet ruznych samostatnych tweeneru pro jeden item...

- v tom destroy jak likvidujes postupne komponenty jednoho gameobjektu - je to potreba? To je nejaky particle system referencovany nekde jinde na jinem gameobjektu a ridi se vymazanim tehle komponenty? Muzu se plest, ale ze zapisu mi pripada, ze proste v destroy resis nejake smazani gameobjektu, co ma na sobe efektiky a podobne - ze nechces vlastne jen selektivne promazavat komponenty, ale smazat cely gameobjekt. Tak to neres. Proste nekde zavolej Destroy(hunt.gameObject) a on proste vystreli cely gameobjekt se vsema podvesenyma komponentama a podobne..

- to rizeni animace a delegace kliku na nekolika mistech pomoci ruznych casovani a navic jeste pomoci Invoke/InvokeRepeating je cesta do pekel. Kdyz uz musis, pouzij aspon coroutiny - pokud by se tweeny neprolinaly, da se normalne yieldovat jeden tween za druhym:

yield return punchScaleTween.WaitForCompletion();
yield return coin.DOFade(0, .4f).SetEase(Ease.OutQuad);

- anebo to v tomhle pripade, kde se ty tweeny prolinaji a podobne - nech teda odridit celou flow tou tween sekvenci. Zvlada i volat callbacky bud kdykoli v prubehu sekvence nebo se da hooknout na konec sekvence, takze mas jistotu, ze to bude posledni vec. Navic se pri destroyi da volat .Complete(true) misto .Kill(), aby vsechny zavazane callbacky zavolal. U toho obcas pouzivam fintu, ze na .OnComplete() rferenci na tween/sekvenci smazu, takze v nejakem destroy vim, jestli jeste jede nebo ne a podle toho cistim.

Takze za me - bych tech par veci (naslepo - nerucim za 100% funkcnost) prepsal aspon zhruba takhle (mrkni hlavne na kod kolem showFoundAnimation, rotation a destroy): https://pastebin.com/12J8SUAd