FREELA: v tomhle pripade mi prijde nejjednodussi, jak uz bylo receno (a pokud to teda muzes udelat), opravdu parentnout hrace na to hriste a pak mu proste jen nastavoval localpos a localrot podle libosti relativne vuci hristi. cili pred spawnem dalsiho hriste si vzit localpos / localrot a po spawnu dalsiho je proste pouzit

FREELA: jestli ti jde jen o rotace v ose Y, teoreticky by ti pro to mely stacit euler angles. Zjisti si eulerY prvniho hriste, eulerY prvniho hrace, udelej mezi nima rozdil (relativni natoceni hrace ke hristi) a pak u druheho hriste otoc noveho hrace stejne relativne k eulerY druheho hriste... To je takove polopaticke.

Pak me napada, za predpokladu, ze by hrac byl v hierarchii primo pod hristem, pouzit transform.localRotation, coz by mela byt relativni rotace vzhledem k parentovi - tedy po spawnu noveho hriste by melo stacit predat novemu hraci stejnou hodnotu local rotation.

Da se to ale resit i primo pres quaterniony, akorat v tom mam dodneska trochu bordel, tak ted mozna budu placat: Mam pocit, ze odectenim dvou quaternionu dostavas relativni rotaci, kterou pak muzes vynasobit jinej quaternion (mozna jeho Quaternion.Inverse hodnotu?) a melo by si to sednout. Ale tohle ted taham trochu z paty. Vim, ze jsem s tema operacema vzdycky chvilku valcil a ve finale zjistil, ze je na to, co potrebuju, nejakej daleko jednodussi postup...

BYDK: Vector3.Distance pouzivam, ale ted mi to nestaci. Zkusim to jeste rozepsat...

Na mape mam fotbalove hriste a to presne vodorovne (leva branka zapad/ prava vychod). Postavim hrace od stredu 3 metry na jih a 4 metry na zapad.

Nasledne spawnuju dalsi hriste, ktere je ale jinde na mape a o 45° clockwise otocene. A ted bych mel podle udaju z toho prvniho hriste zas postavit hrace na stejnou pozici.

FREELA: Jestli to chapu dobre, muzes si ty transformace parentnout. Pak se ti bude zobrazovat to co chces i s rotaci, vzdalenosti. Pohoda. :) Pripadne distance vypocitas: https://docs.unity3d.com/ScriptReference/Vector3.Distance.html

Jeden zacatecnicky dotaz:

Na mape mam bod A (Vector3, Quaternion) a bod B (Vector3, Quaternion)
Potreboval bych vypocitat distance tak, aby se po wipe mapy, na ktere se zobrazi nekde jinde opet a v jine rotaci bod A, zobrazil automaticky bod B a to i natoceny stejnym smerem vuci bodu A.

SHIGORBIRDMAN: Chápu, tak snad to nějak dopadne v rámci možností dobře.
I když někdy by nějaká ta rozumná čistka asi nebyla úplně na škodu. Biť by to bylo bolestné, ale pokud by to mělo pak ušetřit v nějakém rozumném horizontu nervy a lépe a jednoduššeji fungovat nezlobil bych se.

ROLAND: problemy s enginy vzdycky jsou a budou, proste je to velky kus softwaru... ktery si za sebou vetsinou tahne spoustu legacy potizi. Software psany a prepisovany a predelavany pres dvacet let (coz v podsatte plati jak pro unreal, tak uz myslim i pro unity), ktery nebude mit sve potize, to proste imo nejde.

Jak unrealu, tak unity by pomohlo udelat nejaky velky skrt a cistku, ale to si samozrejme netroufnou, uz tak je vsichni proklinaji za pomale upravy a deprekovani opravdu starych a spatnych veci. Unity musim uznat, ze po chaosu a potizich s prechodem na 5 vypada, ze prece jen pomalu nekam kraci a nejen cestou oblibenou drivejsi, koupime nejaky middleware, narveme ho tam, a stare potize ignorujeme. Ale mozna to rikam proto, ze jsem nikdy nezkousel delat neco vetsiho nez mikropokusy s 2017+, protoze pracovne jsem byl nenavratne zaseknuty na suicidal combo 4 & 5

ROLAND: unreal je jeste porad tvrde fixovany "engine na dalsi unreal tournament / gears of war" - spousta legacy veci tam porad zustava (ne ze by unity a legacy veci nebyly problemy, byt pomalicku nasledky toho, ze to kdysi byla puvodne javascriptova sracka mizi). Unity ma problemy s vykonem a pameti, o streamovani nemluve, byt uz je to mnohem lepsi nez byvalo, takze velke open world veci se na nem delaji mimoradne blbe.

Jednorazove demo udelas na unity stejne hezke jako na unrealu s trochou snahy, a mozna se ti i bude hybat :) Velke obrovske aaaargh svety... mozna ze jednou konecne ten garbage collector vyhodi :) (fun fact, unity pro hololens problem nema, protoze bezi na standardnim mrkvim...)

Ale teď jsem si znovu pročetl to tvé story ohledně Unrealu a říkám si jestli některé ty problémy v těch enginech nesouvisí spíše s Windows nebo s OS.
Pokud tedy nepracuješ v Linuxu.
A nebo se nám brzo samozrodí nějaké to AI. ;)

SHIGORBIRDMAN: Ano díky, naštestí mám vesmír, takže jako tam by se to mohlo nějak ztratit. A pořád doufám že půjde rozumě škálovat měnit nějak rozměry a z 30 km pak lehce udělat 3x3km apod.

To s těmi kolizemi se musím zeptat programátora, ale opět naštěstí hra je primitivní, takže nebude vadit moc překrytí. Ale to poskakování by mohlo možná nastat při větším počtu lodí. Ale tak zase snažím se aby ty modely lodí měli málo polygonů a aby to pak pokud možno šlo transportovat na mobilní zařízení. Teď jsem to zatím vypustil.

NaN se už přihodilo u věžiček.

Já tak mám ještě stále loknuté že android a zjednodušeně řečeno na malé či menší věci a Unreal na FPS a open world. I když popravdě ted netuším jak to je. Co jsem viděl to jedno demo v tom lese v Unity tak moc hezké, otázka zní jak by v tom fungovala hra a na jakém HW by to bylo schopno tak běžet.

ROLAND: 30 kilaku x 30 kilaku, realisticke vzdalenosti a rychlosti budou problem. vzdalenost 30 kilometru od nuly uz ti muze vyvolavat viditelne potize kvuli floatum (trepani veci - u dead effectu jsme kvuli tomu museli presouvat vsechny levely rozumne do nuly, protoze pokud byl level par kilaku od nuly, vznikaly viditelne artefakty). vyzkousej, uvidis, ale pocitej s tim, ze problemy se muzou vyskytovat. hlavne nezapomenout na vsechny rychle veci nastavit continuous dynamic detekce kolizi - jinak ti lod klidne proleti jinou lodi a i terenem (pokud to neni standardni heightmap teren z unity, ktery je ale dost nepouzitelny) - nebo dostane pri reseni kolize nesmyslne velke hodnoty, roztoci se ti a rozpadne, nebo dokonce rovnou zmizi, protoze nekde proleze infinity nebo NaN.

Ad Unreal - viz ten elaborat, co jsem tu psal driv. Jsou veci, ve kterych je unreal viditelne a nekdy i citelne lepsi nebo aspon jsou, kdezto v unity je to napis si sam / kup si middleware a doufej ze bude pouzitelny (vykon, garbage collector, polyformni serializace, takze neni potreba resit slozitejsi data externe pres json/xml, multiplayer, ktery je ted v unity hodne spatny, streamovani...). Ale spousta veci je fakt mnohem horsi. Rvani si vlasu kvuli problemu zpusobeny nejakym black magic deep inside byly v unity caste, ale u unrealu mas jedno jedine plus - mas zdrojaky a hypoteticky si to muzes najit a opravit sam (good luck). Zazdene potize, obsolete veci, veci co najednou nefungujou, stare postupy nalezene na answers, ktere uz ale dva tri roky neplati, i oficialni rady a samply, ktere nefunguji... je i v unrealu.



Pricetny engine... uz chut psat si (zase) vlastni znamena, ze se projevuje moje nepricetnost :D Udelat rozumnou fyziku, na tom jsem zabil hezkych par mesicu, prestoze jsem to delal maximalne primitivnim zpusobem, aby to fungovalo rozumne rychle a ne uplne blbe - a pak jsem zacal delat s unity a zjistil, ze physx je taky impulse based a dela uplne stejne picoviny jako to moje :D

(defakto jediny duvod, proc s tim uz zase koketuju je to, ze neexistuje engine, co by umel veci, ktere bych na jeden svuj experimentik potreboval... jinak bych si celkem s jistotou hral s unity, protoze afaik porad neexistuje lepsi system na rychle iterovani a programatorske experimenty)

SHIGORBIRDMAN: Sakryš, to si mě nepotěšil. Ale díky ti.
Já totiž objekty nechal grafika dělat v metrech aby pak bylo i nějak řekněme snašší možné měřítkové škálování objektů. A tak jsem chtěl i nějakou řekněme realistickou rychlost objektů. Takže k mému nespokojení to budu muset zkrátka nějak nafejkovat a budu muset odhadnout.

A tak si nejsem jist jestli jsem neudělal trochu blbost s tím že hrací prostor bude mít velikost asi 30km x 30km. No uvidíme snad mě programátor nezabije.

SHIGORBIRDMAN: Počkat Unreal je také nějak moc špatný? Jako moc bugů než by se dalo řekněme s nějakou tou lehkostí překonat. A ne si při tom rvát vlasy? Jako v Unity jsme před pár lety narazili na problém co byl znám podle dotazu 3 roky tehdy a nikdo jej neopravil. Takže ta věc se pak řešila jinak.

Tak jestli se ti povede příčetný engine, tak prosím ať je možné operovat s fyzikou a aby objekty mohly se pohybovat rychlostí i třeba rychlostí světla. ;)
No a také nějaké fine uživatelské rozhraní a logické ovládání. ;)

SHIGORBIRDMAN: Navíc Unigine zaměstávaj regulerní qa lidi a ti zkrátka choděj na to fórum a odpovídají na různě sofistikované technický dotazy a řeší bugy. A jakože fakt do pár hodin zpravidla odpoví a do druhého dne v případě bugu obvykle analyzujou problém a buď dodaj workaround a nebo ti řeknou, že to v příští verzi nebude. Já vim, že to je v každym normálním korporátu samozřejmé a banální, ale stejně mě to udivuje.

SHIGORBIRDMAN: Výrazně. Je to tak drahý, že tam žádní fanboys nejsou.

JAACOB: My jsme si koupili Unity pro verzi a dlouho v tom dělali a známe to dobře. Jediný co umí fenomenálně je import assetů.



Nezvládalo to technicky velikost světa.
Nezvládalo to práci s assetama a repozitářem a zdrojákama.
Padalo to.
Bylo to pomalý.
Graficky to bylo slabší.
Slabá komunita plná lidí, co by neměli programovat a nebo dělat grafiku. Těžko tam najdeš radu na *složitější* problémy.
Nahovno dokumentace.

Tak nám jednou došla trpělivost a přešli jsme k Unigine, který nemá žádný z těchto problémů:)
Jinak už maj asi půl roku 1st class c# jako Unity. Přidali to právě kvůli snadnosti přechodu od Unity.

MAIMONIDES: a s tou komunitou je to u unigine lepsi? :)

MAIMONIDES: vizualne prijemne - pohoda. Verim, ze s assetama jste si dali hromadu prace. Skoda, ze ve videich jeste neni videt gameplay. Ale drzim pesti, at se vam povede uspesna hra!

Spis jsem si ale rikal proc jste si vybrali Unigine. Odhaduju, ze v tom Uniginu bylo vcelku simple reseni toho time of day treba..?

Netvrdim, ze Unity je nejlepsi - ja bych nemenil hlavne z pohodlnosti kvuli uz zazitemu reseni a zkusenostem. Ale kdybych se zkratka rozhodoval pro engine do hry i jako clovek bez praxe, tak nevim, jestli bych chtel delat pionyra v softwaru, ktery vyuziva jen zrnko lidi oproti necemu lip zdokumentovanemu, s velkou komunitou.

ROLAND: no to ze se ta strela objevi za hlavni mi prijde jako ze se spawne tam, kde driv byla hlaven, takze ten skok musis kompenzovat pridanim k pozici te strely, ne az pri dalsim updatu

SIRLOON: Ano myslím, že jsme tam přidávali i rychlost lodi.
Ale pamatuji se že jsme museli snižovat někde nějak rychlosti.
To bylo u řekněme prototypu Azulgaru.
A já bych se rád tomu vyhnul u mnou navržené hry.
Herní oblast jsem nechal zvětšit na cca 30x30km a nejrychlejší lodě budou dosahovat rychlosti asi 200m/s. Respektive tak je nastavená.
A možná to ještě nechám zvednout až na 500m/s u těch nejrychlejších.

Takže první vodítko střela musí mít rychlost lodě + ještě svou rychlost aby byla rychlejší než loď.
U laserů asi nebude problém ty se fejknou, u raket a torpéd snad také ne. Ale u projektilů nevím.

ROLAND: kdyz davas impuls strele, pricitas k nemu i rychlost lodi?

Měl bych takovou otázku, snad ji zformuluji správně.
Netuší prosím někdo co je za problém, když mám loď která střílí střely tak, že při nějaké rychlosti přestane střílet? Nebo se střely začnou objevovat za hlavní zbraně?

Proč se to tak děje?
Jsou v unity nějaké rychlostní limity?
Jakým způsobem se to řeší?
Prosím vysvětlit jednoduše, laicky.
Díky.