.[ ČeskéHry.cz ].
Table Football Pro - na Greenlightu
Jdi na stránku Předchozí  1, 2, 3, 4, 5  Další
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Hry pro PC, konzole, ...
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
Ladis



Založen: 18. 09. 2007
Příspěvky: 1480
Bydliště: u Prahy

PříspěvekZaslal: 8. květen 2017, 17:32:50    Předmět: Odpovědět s citátem

Těch 200 paketů za sekundu mi přijde jako "udělám tam sleep a v dalších verzích ho budu zmenšovat" Smile. A přes všechno to propracované testování těch 2 DLL doporučuju otestovat hlavně tu latenci ("může" -> "bude", ne každý je přes optiku, spousta je jen přes WiFi, a to se ani neodvažuju uvažovat pomalé free WiFi, např. v restauraci). Jinak doporučuju vykašlat se na "hezkou implementaci", ať ušetříš čas na další herní pokus, než se vrátíš do banky.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 8. květen 2017, 19:47:59    Předmět: Odpovědět s citátem

Smile 200 packetů /s jsem tam měl proto, že FixedUpdate běží 200x za vteřinu a posílat packety rovnou je děsně jednoduché...
Proč 200/s? Ten fotbálek jede čistě přes fyziku a pružina na panáčcích se musí hýbat dost rychle. Když tam dám míň, míček začne při odpalu dělat blbiny.
Jinak jsem samozřejmě nejdřív začal s UNET HLAPI, ale to na mojí hru nepasuje.

O packetlossu na wifinách vím - zatím jsem ho neřešil, Unití simulátor je nejspíš v 5.6ce rozbitý. Asi pro Unreliable komunikaci udělám redundantní posílání minulých zpráv v těch dalších. Nicméně tohle řeší LLAPI v Reliable UDP kanálu samo, tak asi nejdřív začnu s tím.

Neřekl bych, že tu "krásnou implementaci" dělám samoúčelně - je to obrovská zkušenost - jak pro architekturu aplikace, tak pro fungování síťové komunikace. Já mám s herními enginy ten problém, že je to pro mě blackbox a často je problém se vůbec dopátrat, jak co funguje, viz např. https://forum.unity3d.com/threads/the-truth-about-fixedupdate.231637/

Tobě to možná nepřijde (nebo jsi tady jednou byl taky), ale teď už vím, že dokážu udělat síťovou hru a že dokážu hry škálovat hry, co se komplexity funkcí týče.

Nejde mi o to udělat co nejvíc "pokusů", ale pořádnou, odladěnou hru, na kterou můžu být hrdý. A teď už mám knowhow a můžu se soustředit na jiné věci...

Fotbálek musím vydat v květnu v early accesu, do banky nechci ani za zlatou cihlu ... Smile
Pokud odladím tu síť, jdu do toho.
Určitě vám sem dám build na vyzkoušení.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 8. květen 2017, 22:54:54    Předmět: Odpovědět s citátem

Jelikož se mi blíží vydání do Early Accessu, chtěl bych vás požádat o radu.

Zaprvé, nevím jak hru nacenit. Pro mě je férová cena 5 euro, nicméně nevím jestli je to adekvátní.

Zadruhé, nevím, kolik cca můžu očekávat prodejů v za první měsíc Early Accessu. Koukal jsem na steamspy na fotbálkovité hry, a myslím, že řádově tisícovku prodaných kusů můžu považovat za velký úspěch. Jaký na to máte názor / zkušenosti?

Zatřetí - blíží se letní slevy a jestli se jich budu chtít zůčastnit, musím hru vydat určitě ještě v květnu a to brzo. Otázka je, jestli do toho mám jít. Opět bych uvítal názory.

Stav hry spíš brzo nasdílím, asi zítra připravím build.

Moc vám děkuji, hrozně mi to pomáhá! Smile


Naposledy upravil Diskobolos dne 9. květen 2017, 16:00:47, celkově upraveno 1 krát
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Radis



Založen: 29. 03. 2014
Příspěvky: 217

PříspěvekZaslal: 9. květen 2017, 08:30:45    Předmět: Odpovědět s citátem

citace:
Mám hru už snad plně převedenou do backendu.
Na frontendu jsou opravdu jen ty nejnutnější věci týkající se interakce s Unity.

Teda ty s tim Unity silene bojujes. Delas uplne jednoduche veci naprosto nestandardnim zpusobem. Tohle tvoje deleni na "backend" a "frontend", ty DLL... Jako videl jsem uz spousty Unity projektu, ale tohle je vazne unikat Smile

citace:

game loop - celé to tikám z jednoho FixedUpdate

Nevim, jestli te chapu dobre, ale "cele" bys to z fixed update rozhodne tikat nemel. FixedUpdate je framerate independent a mel by se pouzivat jen na veci spojene s fyzikou (napr. pusobeni sily na rigidbody). Treba zpracovavat input ve fixedupdate je vylozene chyba. A to, ze to cele tikas jen "z jednoho" FixedUpdate je, predpokladam, symptom te tvoji architektury, ze? To jako ideal, kteremu se snazis priblizit, je mit jeden gameobject, jeden monobehaviour a vsechno ostatni uplne mimo v tech DLL bez pouziti jedine komponenty?

citace:

síťová komunikace (používám UNET LLAPI) - kromě pár UNET-specifických service class

Proc nepouzivas HLAPI? Co presne tam bylo za problem?

citace:
V testech si ručně "tikám" gameloop, ručně přijímám zprávy přes síť a koukám, co se s nimi děje, atp.

Jen pro jistotu: v Unit testech ty data ve skutecnosti neprijimas pres sit, ze ne? Smile Jinak jak uz jsem rekl, testovani neni problem ani primo v Unity a urcite nebylo nutne kvuli tomu davat vsechno "bokem" do nejakych DLL.

citace:
mám tam implementovaný sběr síťových zpráv, ty se jednou za daný čas vyfiltrují a poskládají do packetu

Co tam posilas za data?

citace:
používám ve hře silně fyziku (ta se v Unity nedá vrátit)

Hlavni problem neni ani tak to, ze by se nedala vratit (to si muzes uz ted nejakym zpusobem udelat "rucne"). Problem je spis to, ze pak nejde rucne simulovat, coz je pro server reconciliation zakladni predpoklad. Ale pred nejakou dobou jsem videl testovaci build Unity, ktery tohle umoznoval (bylo tam neco jako Physics.Simulate(dt)). Jestli si to dobre pamatuju, tak oficialne by to meli do Unity pridat koncem roku.

citace:
tak musím interpolaci bohužel dělat jak na klientovi i na serveru

Tomuhle nejak nerozumim, muzes mi to trochu popsat? Co interpolujes na serveru?

citace:
napsal jsem si vlatní serializaci na úrovni bitů, UNET LLAPI používá pro bool hodnoty celý byte!

Serializace prece vubec neni soucasi LLAPI, ne? Ano, HLAPI pouziva pro bool jeden byte. Je to problem? Kdyz budu potrebovat poslat par booleanu a budu chtit setrit bandwidth, tak pouziju normalni serializaci bytu, ve kterem si rucne nastavim bity. Psat jen kvuli tomuto vlastni serializaci? To snad ne.

citace:

O packetlossu na wifinách vím - zatím jsem ho neřešil, Unití simulátor je nejspíš v 5.6ce rozbitý.

Na simulaci packet lossu (a dalsich veci) muzes pouzit i neco mimo Unity (treba clumsy)

citace:
Asi pro Unreliable komunikaci udělám redundantní posílání minulých zpráv v těch dalších. Nicméně tohle řeší LLAPI v Reliable UDP kanálu samo, tak asi nejdřív začnu s tím.

Proc bys posilal redundatne minule zpravy? Ta hra musi prece umet nejaky rozumny packet loss, out of order messages a latency proste zamaskovat. A nemuzes prece vsechno posilat pres reliable kanal... Jeden dropnuty packet ti zastavi dalsi zpravy az do doby, nez dorazi ACK. U obcasnych zprav to nevadi, ale nemuzes takhle posilat kazdou message 20x za sekundu... Reliable kanal je pro veci, u kterych potrebujes mit jistotu, ze dorazi. Pro data, ktera se meni casto (pozice micku) se standardne pouziva unreliable kanal.

citace:
Neřekl bych, že tu "krásnou implementaci" dělám samoúčelně - je to obrovská zkušenost

Tobe to mozna pripada jako krasna implementace, mne to pripada jako sileny over-engineering a implementace uplne proti filozofii Unity.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 10:02:32    Předmět: Odpovědět s citátem

Bojuju, už dlouho.
Podívej se např. na kód na téhle stránce dole: https://docs.unity3d.com/540/Documentation/Manual/UNetInternetServicesOverview.html
Tobě se ten kód líbí? Tady mám problém s Unity - data, logika, gui - všechno se namatlá do jedné god-classy a pověsí někam na gameobject jako na vánoční stromeček.
Unity nedává návod, jak udělat rozumnou udržovatelnou architekturu, jen hromadu copy-paste samples. A konkrétně k tomuhle navíc mizernou dokumentaci.

Ad FixedUpdate - vím, na co má být FixedUpdate, ale když se podíváš na ten link, co jsem posílal, je tam celkem vášnivá debata a taky se dočteš, že to nemusí být jen na fyziku - ale na věci, které nemají být závislé na framerate - např. AI. Otázka je, jestli to dávat do FixedUpdate a nebo si na tyhle věci udělat separátní timer.
Zpracovávát input ve FixedUpdate je chyba, vím, ale používám Rewired a ten to podporuje, takže chyba to u mě není.
Vím, že s FixedUpdate je problém, když překročím časový limit, který na jeden tick má a tohle musím řešit.
Jestli je to důsledek mojí architektury? Ne nutně. Můžu si tam zavést i tick pro Update() loop a přesunout konkrétní logiku do ní.
Celé jsem to podřídil jednomu ticku z toho důvodu, že můžu ovlivňovat pořadí, ve kterém se logika provádí. Jak to řešíte vy? Script execution order? Opravdu? Smile

Neber to, že se navážím do Unity nebo do vašeho přístupu - rád bych si nad tímhle sednul s někým zkušeným a možná mi ukážete jednodušší cestu. Pro mě je standardní přístup Unity prostě neudržovatelný, netestovatelný black box.
Důvod, proč jsem se do backendu pustil, bylo tohle: https://www.youtube.com/watch?v=TvYQQ5okA88&feature=youtu.be&t=1284
Já prostě nebyl schopný hru nějak rozumně vyvíjet/testovat a to mě děsí.


Radis napsal:
citace:
Mám hru už snad plně převedenou do backendu.
Na frontendu jsou opravdu jen ty nejnutnější věci týkající se interakce s Unity.

Teda ty s tim Unity silene bojujes. Delas uplne jednoduche veci naprosto nestandardnim zpusobem. Tohle tvoje deleni na "backend" a "frontend", ty DLL... Jako videl jsem uz spousty Unity projektu, ale tohle je vazne unikat Smile
citace:

game loop - celé to tikám z jednoho FixedUpdate

Nevim, jestli te chapu dobre, ale "cele" bys to z fixed update rozhodne tikat nemel. FixedUpdate je framerate independent a mel by se pouzivat jen na veci spojene s fyzikou (napr. pusobeni sily na rigidbody). Treba zpracovavat input ve fixedupdate je vylozene chyba. A to, ze to cele tikas jen "z jednoho" FixedUpdate je, predpokladam, symptom te tvoji architektury, ze? To jako ideal, kteremu se snazis priblizit, je mit jeden gameobject, jeden monobehaviour a vsechno ostatni uplne mimo v tech DLL bez pouziti jedine komponenty?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 10:35:02    Předmět: Odpovědět s citátem

Ad HLAPI:
Hrál jsem si s tím, ale narazil jsem tam na problém s vlastnictvím objektů. Mám autoritativní server a kopnutí do míčku se musí provést tam. Jenže pawna chci ovládat (=vlastnit) lokálně. Tzn. když ho ovládám, vlastní ho klient, ale jakmile ho pustím, má ho vlastnit server a výstřel provést tam.
Takhle to na server jen sporadicky přeneslo pár pozic panáčka při výstřelu, ale neprovedl se tam samostatný výstřel.
Vím, že tam je podporovaný přenos vlastnictví, ale nemyslím si, že to bude fungovat realtimově spolu s tím výstřelem. Chvíli jsem to zkoušel a nefungovalo mi to.

Druhá věc s HLAPI - opět je tam ten antipattern (alespoň pro mě) - opět se síť věší na gameobjecty jako na vánoční stromeček. Když chci mít síťovou a singleplayer hru, musím mít dvě sady prefabů. Když bych chtěl přepnout na jinou síťovou implementaci, musím přepsat kompletně všechny objekty ve hře (při použití LLAPI můžeš celou síť schovat za rozhraní a dát tam jinou implementaci, když bude třeba). Samotní autoři říkají, že HLAPI je ukázková implementace nad LLAPI. Opět cesta, jak to snadno a rychle rozchodit, ale pak už máš svázané ruce a nulovou kontrolu.

Ad Unit testy - neříkal jsem, že dělám Unit testy, ale funkční testy - ty testují celé části backendu. Neposílám nic přes síť (Unití classy nefungují mimo Unity - to dělá ta jejich C++ implementace s C# wrapperem), ale posílám serializovaná data přes mock té sítě, takže testuji celou cestu - deserializaci, zpracování, atp. Tady dělám testy jen na happy path, případné důležité scénáře - chci dodělat testy pro stabilitu serveru, když se odpojí klient při loadu levelu, atp.

Posílaná data:
- server posílá pozici míčku (pos, rot, linearVelocity, angularVelocity)
- klienti posílají rotaci panáčků (heading, tilt) + dva booly: ovládám? vystřelil jsem?
- server posílá rotaci panáčků od druhého hráče

Ad vlastní serializer - mrkni na UnityEngine.Networking.NetworkWriter.Write(bool value)
Ano - mohl bych přeskládat strukturu packetů tak, aby bool byly za sebou a pak je sázet do byte, ale proč, když si můžu napsat vlastní implementaci používající BitArray? Měl jsem to za pár hodin a už na to nemusím myslet...

BTW: celé tohle vychází od poznatků tohohle šikuly: http://gafferongames.com/networked-physics/snapshots-and-interpolation/
(já koukal na video, tohle je detailnější prezentace)

Ad redundantní zprávy - v tom článku výše to taky dělá a dává mi to smysl, pokud budou packety dostatečně malé, aby se to tam vešlo.
Pozici míčku můžu při packetlossu na klientech klidně oželet.
Ale nemůžu oželet výstřel panáčka - ten se prostě na server dostat musí.
LLAPI má ještě něco nad Reliable, kde si můžeš nastavit, aby posílal zprávu opakovaně už dřív než RTT (jak je to v Reliable), ale když bych to přibalil do další zprávy, tak to může taky fungovat (za předpokladu, že mám dostatečně rychlý network tickrate, jinak to nemá smysl a bude lepší použít to od Unity).

S těmi reliable packety čekajícími ve frontě to ještě nemám nastudované.. LLAPI je nad UDP, tak že Unity tam má vlastní frontu a může se to tam zdržovat?
Já tam měl na tahle data unreliable kanál - jen jsem se dočetl, že Unity v případě reliable posílá data stejně, jen je pošle znovu, pokud nastane RTT a nedostane do té doby ack, tak jsem to zkusil přepnout, jestli to bude fungovat. Ale jak říkám, ještě jsem neřešil konkrétní metodu, jak ten packetloss řešit. Ad externí tooly - dík, mrknu!

Radis napsal:

citace:

síťová komunikace (používám UNET LLAPI) - kromě pár UNET-specifických service class

Proc nepouzivas HLAPI? Co presne tam bylo za problem?

citace:
V testech si ručně "tikám" gameloop, ručně přijímám zprávy přes síť a koukám, co se s nimi děje, atp.

Jen pro jistotu: v Unit testech ty data ve skutecnosti neprijimas pres sit, ze ne? Smile Jinak jak uz jsem rekl, testovani neni problem ani primo v Unity a urcite nebylo nutne kvuli tomu davat vsechno "bokem" do nejakych DLL.

citace:
mám tam implementovaný sběr síťových zpráv, ty se jednou za daný čas vyfiltrují a poskládají do packetu

Co tam posilas za data?

citace:
tak musím interpolaci bohužel dělat jak na klientovi i na serveru

Tomuhle nejak nerozumim, muzes mi to trochu popsat? Co interpolujes na serveru?

citace:
napsal jsem si vlatní serializaci na úrovni bitů, UNET LLAPI používá pro bool hodnoty celý byte!

Serializace prece vubec neni soucasi LLAPI, ne? Ano, HLAPI pouziva pro bool jeden byte. Je to problem? Kdyz budu potrebovat poslat par booleanu a budu chtit setrit bandwidth, tak pouziju normalni serializaci bytu, ve kterem si rucne nastavim bity. Psat jen kvuli tomuto vlastni serializaci? To snad ne.

citace:
Asi pro Unreliable komunikaci udělám redundantní posílání minulých zpráv v těch dalších. Nicméně tohle řeší LLAPI v Reliable UDP kanálu samo, tak asi nejdřív začnu s tím.

Proc bys posilal redundatne minule zpravy? Ta hra musi prece umet nejaky rozumny packet loss, out of order messages a latency proste zamaskovat. A nemuzes prece vsechno posilat pres reliable kanal... Jeden dropnuty packet ti zastavi dalsi zpravy az do doby, nez dorazi ACK. U obcasnych zprav to nevadi, ale nemuzes takhle posilat kazdou message 20x za sekundu... Reliable kanal je pro veci, u kterych potrebujes mit jistotu, ze dorazi. Pro data, ktera se meni casto (pozice micku) se standardne pouziva unreliable kanal.


Naposledy upravil Diskobolos dne 9. květen 2017, 11:53:44, celkově upraveno 2 krát
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 11:24:38    Předmět: Odpovědět s citátem

Ad fyzika po síti (tohle bude delší, omlouvám se):
Celá hra je o tom, že páčkou na gamepadu si natočím panáčka, počkám, až se míček usadí tam, kde ho potřebuju a pak páčku pustím - tím panáček kopne do míče a ten odletí.

Ovládaný panáček = kinematic rigid body
Panáček, co vystřelil = non-kinematic ridid body s pružinou
Míček si pak letí svojí cestou.

Panáčka ovládám lokálně, přes síť se synchronizuje rotace + tilt na server a z něj pak na druhého klienta.
V okamžiku, kdy panáčka na klientovi pustím:
1/ na server dojde spolu s rotací i info, že jsem ho pustil a
2/ panáček na serveru vystřelí na do skutečného míčku
3/ Výstřel panáčka na serveru se pošle i na druhého klienta a server taky pošle pozice míčku na oba klienty.


Do jednoho packetu (tickrate je např. 20x/s) dám předem daný počet zpráv, které za těch 1/20s nastaly.
Zpráva je logická část packetu, např.:
- pozice míčku (posílá server)
- rotace pawnů (server i klient)

Každou zprávu opatřím časem a na klientovi pak tyhle pozice postupně přehrávám podle času v jakém nastaly. Server i klient mají při začátku hry čas 0. Počítá se s tím, že čas na klientovi bude posunutý o Round Trip Time (RTT).

Tou "Interpolací" myslím síťovou interpolaci jak je popsaná např. zde http://gafferongames.com/networked-physics/snapshots-and-interpolation/ (client-side interpolation).
Ve zkratce - zobrazuji minulost. Přijmu zprávy do fronty a postupně je pouštím do hry, ale až za určitý čas, větší než je RTT/2. Tím se vyhladí menší výpadky sítě, atp. A dělám to jak na klientovi, tak na serveru, viz dole.

Problémy s tímhle setupem:

Latence:
1/ když vystřelím, z klienta se zpráva odešle průměrně za 25ms (při 50ms network tickrate)
2/ na server se dostane za RTT/2
3/ na serveru se zpracuje za RTT/2 + něco na interpolaci
4/ ze serveru se výsledek odešle za server network tickrate (taky 25ms)
5/ na oba klienty zpět zase za další RTT/2, ... a tak dále...
Na malém pingu je to ok. Větší latence musím testovat.

Důsledky:
Když chci na klientovi rychle vystřelit - na serveru je míček trochu jinde a míření nemusí být přesné. Ale hra spíš vede k tomu, že počkáš, až se míček uklidní a polohy budou stejné, tak to nebude zase takový problém.

Na klientovi je míček plnohodntný rigid body, kterému ze serveru nastavuji natvrdo polohu, rotaci, rychlost. Když data nepřijdou, koulí se sám. Tohle není problém, míček se netrhá když mu pošlu a nastavím i rychlosti.
Nicméně když do něj šťouchnu na klientovi, okamžitě se pohne. Ale server ho hned vrátí zpátky, protože na serveru (v minulosti) je míček ještě u panáčka. Tohle kazí dojem plynulé hry - vystřelím, míček rychle odskočí, pak se vrátí zpět a zase odskočí.
Tady jsem přemýšlel, že bych udělal lerp pozice v tom smyslu, že ihned po výstřelu lokálním panáčkem by se ignorovala pozice míčku serveru a za krátký čas se postupně plynule přešlo na pozici serveru. Ale ten čas nesmí být příliš velký, protože cesty míčku se můžou a budou dramaticky lišit.

Takže konečně k otázce, proč dělám "Client Side Interpolation" i na serveru:
Na serveru se nevracím v čase, kde byl míček, když klient vystřelil, abych retrospektivně upravil pozici míčku a "dosimuloval" ho do podoby, která je teď na klientovi, který vystřelil. Tady hraje roli efekt motýlích křídel a míček může být za tu dobu kdekoli. Navíc mezi tím se míček na serveru už hýbě a jeho pozice jsem ze serveru poslal.
Teoreticky bych se mohl vzdát autoritativního serveru a delegovat vlastnictví míčku na klienta, který má míč, ale:
- během vteřiny se může odrazit od tří panáčků, takže tohle udržovat a ladit by bylo složité
- povolil bych tím cheatování

Na takhle malou hru je to celkem složité, žejo? Smile


Radis napsal:

citace:
používám ve hře silně fyziku (ta se v Unity nedá vrátit)

Hlavni problem neni ani tak to, ze by se nedala vratit (to si muzes uz ted nejakym zpusobem udelat "rucne"). Problem je spis to, ze pak nejde rucne simulovat, coz je pro server reconciliation zakladni predpoklad. Ale pred nejakou dobou jsem videl testovaci build Unity, ktery tohle umoznoval (bylo tam neco jako Physics.Simulate(dt)). Jestli si to dobre pamatuju, tak oficialne by to meli do Unity pridat koncem roku.

citace:
tak musím interpolaci bohužel dělat jak na klientovi i na serveru

Tomuhle nejak nerozumim, muzes mi to trochu popsat? Co interpolujes na serveru?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Radis



Založen: 29. 03. 2014
Příspěvky: 217

PříspěvekZaslal: 9. květen 2017, 14:52:03    Předmět: Odpovědět s citátem

citace:
Tobě se ten kód líbí? Tady mám problém s Unity - data, logika, gui - všechno se namatlá do jedné god-classy a pověsí někam na gameobject jako na vánoční stromeček.

Tohle je jen sample kod, Unity prece zadnym zpusobem nevynucuje, abys programoval takto. V produkcnim kodu asi nikdo UI kod s logikou nemicha a nerve vsechno do jedne tridy, tohle je proste ukazka, ktera na par radcich co nejjednoduseji ukazuje urcitou funkcnost. Jako sample kod mi to prijde v pohode.

citace:
nemusí být jen na fyziku - ale na věci, které nemají být závislé na framerate - např. AI. Otázka je, jestli to dávat do FixedUpdate a nebo si na tyhle věci udělat separátní timer.

Ja bych to takhle (obecne) nedelal. Chapu, ze muzou byt pripady, kdy to muze byt nejpragmatictejsi reseni, nicmene standard by IMHO byl delat tyhle veci v Update a merit si cas separatne.

citace:
Jestli je to důsledek mojí architektury? Ne nutně. Můžu si tam zavést i tick pro Update() loop a přesunout konkrétní logiku do ní.

Spis jsem mel na mysli to "z jednoho mista", coz je v Unity dost netypicke reseni. Predstavuju si to tak, ze MonoBehaviours se vyhybas za kazdou cenu.

citace:
Celé jsem to podřídil jednomu ticku z toho důvodu, že můžu ovlivňovat pořadí, ve kterém se logika provádí. Jak to řešíte vy? Script execution order? Opravdu?

Nejlepsi je temporal coupling uplne eliminovat, samozrejme nekdy to nejde a pak volam "updaty" rucne z nejake tridy. Script execution order nepouzivam...

citace:
Hrál jsem si s tím, ale narazil jsem tam na problém s vlastnictvím objektů. Mám autoritativní server a kopnutí do míčku se musí provést tam. Jenže pawna chci ovládat (=vlastnit) lokálně. Tzn. když ho ovládám, vlastní ho klient, ale jakmile ho pustím, má ho vlastnit server a výstřel provést tam.

A proc bys mel resit nejakou zmenu vlastnictvi? Tomu nerozumim. Proste kdyz ovladas pawna, tak posilej na server unreliable commandy s jeho pozici a v okamziku vystrelu reliable command o vystrelu se vsim, co server k provedeni toho vystrelu potrebuje vedet. Tohle rozhodne neni nic, co by se nedalo vyresit v HLAPI.

citace:
Druhá věc s HLAPI - opět je tam ten antipattern (alespoň pro mě) - opět se síť věší na gameobjecty jako na vánoční stromeček.

Takze tobe prijde, ze entity-component je v gamedevu antipattern? Na to se mi snad ani nechce reagovat Smile

citace:
Když chci mít síťovou a singleplayer hru, musím mít dvě sady prefabů

Proc presne? Ja jsem to takhle teda nikdy nemel Smile

citace:
Když bych chtěl přepnout na jinou síťovou implementaci

YAGNI. Zbytecne si pridelavas praci, zbytecne generalizujes a zvetsujes komplexitu projektu kvuli eventualite, ktera na 99 % nenastane.

citace:
musím přepsat kompletně všechny objekty ve hře

Jestli ti kazda trida ve hre saha primo na network kod, tak mozna jo Smile

citace:
Ad Unit testy - neříkal jsem, že dělám Unit testy, ale funkční testy - ty testují celé části backendu.

No to je jedno, nenapada me zadny test, ktery bys nebyl schopny udelat v Unity, ale mimo Unity nad nejakym DLL ano. Kazdopadne jednotkove a integracni testovani ma v Unity peknou podporu.

citace:
Tohle kazí dojem plynulé hry - vystřelím, míček rychle odskočí, pak se vrátí zpět a zase odskočí.

Tenhle problem tam proste vzdycky bude, tohle je zrovna typ hry, kde se latence maskuje mnohem hur nez treba u FPS. Nejjednodussi reseni by bylo proste pri vystrelu poslat command na server a lokalne nechat hrace "natazeneho", az dokud nedojdou data zpatky ze serveru. Samozrejme to neni uplne ideal, ale u tohoto typu hry si myslim, ze by to nemuselo vypadat zase tak hrozne a je to urcite lepsi, nez kdyz micek odskoci, pak se teleportuje zpatky a odskoci znovu. Takhle fungoval kdysi Quake. Zmacknul jsi klavesu a pak za 200 ms ses teprve pohnul Smile

citace:
Takže konečně k otázce, proč dělám "Client Side Interpolation" i na serveru

I pres to vysvetleni porad nechapu, proc interpolujes na serveru. Co presne tam interpolujes?

Jinak predpokladam, ze hra bude P2P?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 15:01:56    Předmět: Odpovědět s citátem

Jak jsem slíbil, posílám build fotbálku na vyzkoušení.
https://s3-eu-west-1.amazonaws.com/ticklersoft/fotbal/Builds/football_client_35.zip

Prosím o feedback a předem moc děkuji!
Zkuste to prosím brát s ohledem na to, že bych rád během května šel do early accessu - tzn. hlásit věci, které jsou opravdu špatně a musí se fixnout ASAP.

Instrukce:
- detaily - very high nedávejte, je tam spousta image filtrů a pro velké rozlišení to bude trhat, u mě funguje dobře high ... ještě s tím budu hýbat.
- navigace v menu / hře: klikem myší nebo na gamepadu (A=Confirm, B=Back, X=in game menu). Na klávesnici pro návrat zpět v menu zkuste Esc nebo Backspace.
- síťovou hru nevyzkoušíte, nemám nastartovaný dedicated server, můžem se dohodnout na čase a spustím je - plánuju ho dát na amazon, ale zatím jsem se k tomu nedostal
- single player jde hrát PvP nebo vs. AI (stačí pro daný tým nevybrat ovladač)
- ovládat se to dá nejlépe na myši a gamepadech. Na myši se musí podržet levé tlačítko, natáhnout a pustit. Na gamepadu stačí natáhnout levou páčku a pustit.
Používám Rewired plugin, takže by to snad mělo gamepad poznat. Kdyby ne, dejte vědět. Časem přidělám mapping screenu.

Ve hře:
- míček se může zaseknout, ale dal jsem tam stuck timer, resetne to
- jsou tam místa, odkud má AI problém střílet / přihrávat, vím, opravím povrch
- hra za vás sama vybírá, koho právě ovládáte - může to být neintuitivní, ale nic lepšího nemám. Jsou s tím problémy zejména když center střílí na bránu, já bráním s brankářem a míček proletí kolem středního obránce - na chvíli se to na něj přepne a brankář přestane bránit. Vím, pořeším.
- hra se zatím ovládá na levé páčce gamepadu - předtím jsem tam měl i podporu split controls, tzn. možnost ovládat různé panáčky na každé páčce, ale dost se to pletlo, tak jsem to zatím vyndal
- kruhy okolo hráčů - s tímhle ještě budu pravděpodobně hýbat - motiv za tím je, že když to hraje na gamepadech víc lidí, dost těžko se poznává, kdo s čím může hýbat - takhle má každý svojí barvu. Ale určitě by to nemělo být ve hře 1v1. Navíc když má hráč červené kruhy a modrý tým, děsně se to plete ... taky ještě budu řešit...

Menu:
- vím, je nedodělané, chybí tam hlavně nápověda, jak to ovládat, ikony pro navigaci, atp. Network menu je taky mimo.
- pokud to ovládáte na gamepadu, občas se může ztratit focus, pak je nutno zase myší - opět, vím, pořeším


Naposledy upravil Diskobolos dne 9. květen 2017, 16:01:18, celkově upraveno 2 krát
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 15:35:52    Předmět: Odpovědět s citátem

Díky moc, že mi věnuješ čas, vážím si toho.

Diskusi o HLAPI bych raději přesunul do jiného vlákna.

Ad Entity-Component architektura - asi jsem se nevyjádřil jasně - mně se ta architektura líbí, proto dělám v Unity. Předtím jsem zkoušel UDK a to byl teprve mazec.. Problém mám s tím, že mi přijde nepřirozené do těch komponent matlat herní logiku (nebo nedejbože integraci hry s okolím) pro cokoli jiného než prototyp. U webové aplikace je to ekvivalent toho, že bych z libovolné stránky mohl přímo měnit cokoli v databázi nebo na filesystému.

Já nemám na frontendu jen jedno "FixedUpdate view", já jich tam mám spoustu - jen neobsahují herní logiku ani data. Např. view pro míček reaguje na eventy z backendu a spawne/despawne míček, pošle aktuální pozici míčku (server) nebo ji naopak nastaví (klient). Nicméně model míčku mám na backendu - obsahuje stav míčku a jeho pozici (rychlost, atp.)

Já to tady moc nerozepisoval, ale drtivá většina API z Unity nejde zavolat mimo Unity - to je kvůli té C++ implementaci s C# wrapperem. Classy můžu na backendu odkazovat a používat věci jako Vector3, Quaternion, atp., ale už třeba nemůžu zavolat Quaternion.LookAt. Natož pak něco jako NetworkTransport.Receive(). Takže backend je opravdu backend a cokoli, co se musí volat z Unity je frontend (nebo přesněji Unity-specific).
Takže samotná fyzika běží na frontendu - pokud nechci používat něco jiného (Bullet physics, ...), tak to jinak nejde.

Ad P2P hra - zatím tam tuhle podporu nemám, jen pro dedikovaný server a klienta. Musel jsem se rozhodnout, proč tam tu síť vlastně dávat a problém s "couch coop" hrami je v tom, že si to koupím a nemusím si to mít s kým zahrát. Proto jsem tam dal matchmaking. Ale kdybych ho chtěl udělat P2P, bude mít host vždy výhodu a může cheatovat nebo třeba vytáhnout kabel a klient nic nezmůže. Proto ten dedicated server.

Další důvod je, že dedikované servery mám pod kontrolou a můžu do nich dodělat věci jako turnaje, které by přes P2P nebyly bezpečné.

Nicméně chápu i use case, že si chtějí kamarádi zahrát spolu. Hra je na Steam, tak by bylo super tam mít možnost se joinout na pozvánku pro přátelský zápas. K tomu by se hodilo zase používat síťové API steamu. To zatím nepodoporuji.

Negativum - provozovat dedikované servery pro dva hráče je trochu overkill, vím to. Tady je právě moje váhání nad tím, jestli UNET je ta správná cesta (mají tam zpoplatněný traffic i počet slotů) a nechci být totálně závislý na jejich službách. Pro mě to není YAGNI ale potenciální díra na peníze.

Nicméně nepočítám, že to budou hrát tisíce lidí.
Budu spíš mít problém těch pár serverů zaplnit.
Tady je hrozně zajímavý článek o multiplayeru a indie hrách: http://www.gamasutra.com/view/feature/217434/the_ups_and_downs_of_doing_online_.php?print=1
Jeden tam píše, že počítal s tím, že multiplayer znamená, že se hráči bokem domluví, že chtějí hrát a pak se tam připojí - ale hráči si stěžovali na to, že to nikdo nehraje a že jim hra "sama nikoho nenajde".

Nevím, jak tohle dopadne u mě - mám tam matchmaking, takže když někdo hledá hru, druhého připojí hned k němu. Když nikdo jiný hru nehledá, má peška. Kamarádi se můžou domluvit mimo hru.
Napadlo mě nedostatek anonymních hráčů řešit přes ingame chat nebo aspoň statistiky online hráčů (x hráčů čeká v lobby, atp.).

citace:

citace:
Jestli je to důsledek mojí architektury? Ne nutně. Můžu si tam zavést i tick pro Update() loop a přesunout konkrétní logiku do ní.

Spis jsem mel na mysli to "z jednoho mista", coz je v Unity dost netypicke reseni. Predstavuju si to tak, ze MonoBehaviours se vyhybas za kazdou cenu.

citace:
Druhá věc s HLAPI - opět je tam ten antipattern (alespoň pro mě) - opět se síť věší na gameobjecty jako na vánoční stromeček.

Takze tobe prijde, ze entity-component je v gamedevu antipattern? Na to se mi snad ani nechce reagovat Smile

citace:
Když bych chtěl přepnout na jinou síťovou implementaci

YAGNI. Zbytecne si pridelavas praci, zbytecne generalizujes a zvetsujes komplexitu projektu kvuli eventualite, ktera na 99 % nenastane.

Jinak predpokladam, ze hra bude P2P?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 9. květen 2017, 17:58:41    Předmět: Odpovědět s citátem

Ok, beru. Jen jsem nikde neviděl, že by Unity propagovala nějaký best practices na architekturu a to mě celkem zaráží. Já celkem dlouho hledal a na nic lepšího nepřišel. Možná mi něco ušlo, ale studoval jsem fakt dlouho.
Jak jsem psal - problém frameworků je často ten, že ho používáš víc, než bys měl. A to platí i pro Entity-Component framework.

Radis napsal:
citace:
Tobě se ten kód líbí? Tady mám problém s Unity - data, logika, gui - všechno se namatlá do jedné god-classy a pověsí někam na gameobject jako na vánoční stromeček.

Tohle je jen sample kod, Unity prece zadnym zpusobem nevynucuje, abys programoval takto. V produkcnim kodu asi nikdo UI kod s logikou nemicha a nerve vsechno do jedne tridy, tohle je proste ukazka, ktera na par radcich co nejjednoduseji ukazuje urcitou funkcnost. Jako sample kod mi to prijde v pohode.


Souhlas. Já mám vše ve FixedUpdate, protože mám fyzikální hru a nechci to komplikovat tím, že to budu dělit mezi Update a FixedUpdate. Možná budu časem muset.
Radis napsal:
citace:
nemusí být jen na fyziku - ale na věci, které nemají být závislé na framerate - např. AI. Otázka je, jestli to dávat do FixedUpdate a nebo si na tyhle věci udělat separátní timer.

Ja bych to takhle (obecne) nedelal. Chapu, ze muzou byt pripady, kdy to muze byt nejpragmatictejsi reseni, nicmene standard by IMHO byl delat tyhle veci v Update a merit si cas separatne.


Takže vlastně děláš podobné řešení, já jen ho tam mám zabudové rovnou.
Radis napsal:
citace:
Celé jsem to podřídil jednomu ticku z toho důvodu, že můžu ovlivňovat pořadí, ve kterém se logika provádí. Jak to řešíte vy? Script execution order? Opravdu?

Nejlepsi je temporal coupling uplne eliminovat, samozrejme nekdy to nejde a pak volam "updaty" rucne z nejake tridy. Script execution order nepouzivam...


No .. ano, ale můžu udělat testy čistě backendu - aniž bych při tom musel startovat Unity a nebo řešit, co se děje na frontendu. Zaprvé můžu tyhle testy pouštět kdekoli, třeba i na Continuous integration serveru a taky vím, že pokud ve hře něco nefunguje (a backend je ok), že mám tu chybu hledat na frontendu. V neposlední řadě - můžu si dělit kód do knihoven - mám kód pro klienta a server zvlášť a to i na úrovni kompilace. Jak chceš v Unity snadno zajistit, že kód serveru nesahá na třídy klienta a naopak? Já s tím problém měl.
Radis napsal:
citace:
Ad Unit testy - neříkal jsem, že dělám Unit testy, ale funkční testy - ty testují celé části backendu.

No to je jedno, nenapada me zadny test, ktery bys nebyl schopny udelat v Unity, ale mimo Unity nad nejakym DLL ano. Kazdopadne jednotkove a integracni testovani ma v Unity peknou podporu.



Jj, tohle mě taky napadlo, ale raději bych ten výstřel měl hned a ten míček zkusil zamaskovat, jak jsem psal.
Radis napsal:

citace:
Tohle kazí dojem plynulé hry - vystřelím, míček rychle odskočí, pak se vrátí zpět a zase odskočí.

Tenhle problem tam proste vzdycky bude, tohle je zrovna typ hry, kde se latence maskuje mnohem hur nez treba u FPS. Nejjednodussi reseni by bylo proste pri vystrelu poslat command na server a lokalne nechat hrace "natazeneho", az dokud nedojdou data zpatky ze serveru. Samozrejme to neni uplne ideal, ale u tohoto typu hry si myslim, ze by to nemuselo vypadat zase tak hrozne a je to urcite lepsi, nez kdyz micek odskoci, pak se teleportuje zpatky a odskoci znovu. Takhle fungoval kdysi Quake. Zmacknul jsi klavesu a pak za 200 ms ses teprve pohnul Smile



Ta "Client Side Interpolation" je podle mě dost nešťastný pojem, ale možná mám jen hokej v termínech. Já to pochopil tak, že to je v podstatě buffer, kam dávám příchozí zprávy a snažím se eliminovat nepravidelnost v přijímaní packetů. Takže si udělám časovou rezervu, aby jich většina stihla přijít, byť za cenu přidaného zpoždění, a prostě je pustím do aplikace později, ve správném pořadí a časových rozestupech. Kdyby mi nějaký packet vypadnul, pořád mám dostatek informací na to, abych mohl v předstihu reagovat na výpadek (a třeba dopočítat hodnotu z předchozího a následujícího - proto asi ta interpolace).
Pokud je moje chápání správně, pak to samé potřebuje i server, nejen klient. Tam ty packety budou taky chodit nepravidelně a je třeba je "vyhladit".
Vyjímka můžou být FPS hry, kde výstřel u klienta může server posoudit i okamžitě (protože musí vrátit čas a posoudit, jestli někoho trefil a nemusí na nic čekat), ale nevím, jak přesně to dělají.
Já vracet čas nemůžu.

Ten buffer tam mám, jen zatím nic neinterpoluji. Když se zpráva trochu zpozdí, pořád je možnost, že se jí dočkám včas (nebo si jí pošlu v dalším packetu redundantně). Když vypadne úplně, nic neřeším.

Jak píše na tom blogu, extrapolace na tenhle typ fyziky nefunguje.
Client side prediction a reconciliation může fungovat, ale jen omezeně, jak jsem psal - pro krátkou dobu po výstřelu.
Jestli motám pojmy, tak se omlouvám.
Radis napsal:
citace:
Takže konečně k otázce, proč dělám "Client Side Interpolation" i na serveru

I pres to vysvetleni porad nechapu, proc interpolujes na serveru. Co presne tam interpolujes?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Ladis



Založen: 18. 09. 2007
Příspěvky: 1480
Bydliště: u Prahy

PříspěvekZaslal: 10. květen 2017, 01:19:42    Předmět: Odpovědět s citátem

Vyzkoušel jsem hru a moc zábavné mi to nepřijde. Je to takové napůl turn based - čekám, kam se rozhodne protihráč vystřelit míč z důlku u svého panáčka (a ani si nějak nemůžu vybrat, kterým svým panákem hraju). Stolní hokej je lepší...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Diskobolos



Založen: 14. 03. 2017
Příspěvky: 63
Bydliště: Praha

PříspěvekZaslal: 10. květen 2017, 08:32:01    Předmět: Odpovědět s citátem

Dík za vyzkoušení!
No je to přesně jako ten stolní fotbálek. Můžeš to srovnat s kulečníkem. Jediná věc navíc, co jsme v reálu nehráli - můžeš bránit a blokovat protivníkovy střely.
Vím, že to není vrchol zábavy, ale ten fotbálek si podle mě remake zaslouží. Už kvůli té nostalgii.

Dají se tam vymyslet dodatečné herní režimy - např. udělat z míčku bombu s doutnákem a snažit se to kopnout na protivníkovu stranu hřiště, myslíš, že by to mělo cenu?

Chtěl jsem to vydat čistě jako "couch coop", ale kamarádi mě nalomili - že když nemám s kým si zahrát, mám smůlu, tak jsem dodělal AI i online hru. I když lokální PvP hru považuju za nejzábavnější.
AI je spíš na trénink a online jsem chtěl směrovat na hodnocené kompetetivní zápasy.

Do plné verze chci udělat dvě věci:
1/ ten kompetetivní multiplayer, patrně udělat něco jako rank přes Steam leaderboards.
2/ možnosti customizace hřiště a týmu - skiny, loga, barvy, atp.

Ad nemožnost vybrat si figurku - už jsem to psal. Můžu přidat nějakou formu přepínání, ale podle mě to bude spíš matoucí. Většinou chceš zblokovat střelu na bránu a proto tyhle panáčky vybírám.

Ladis napsal:
Vyzkoušel jsem hru a moc zábavné mi to nepřijde. Je to takové napůl turn based - čekám, kam se rozhodne protihráč vystřelit míč z důlku u svého panáčka (a ani si nějak nemůžu vybrat, kterým svým panákem hraju). Stolní hokej je lepší...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Radis



Založen: 29. 03. 2014
Příspěvky: 217

PříspěvekZaslal: 10. květen 2017, 08:57:31    Předmět: Odpovědět s citátem

Asi jen nejsem cilovka, ale ani me to moc nebavilo. Udelal bych to nejak vic arkadove, nejake powerupy do kterych by se hraci mohli trefovat, nejake zrychlovani micku a takove veci. Ale celkove se z toho konceptu uz asi moc vyzdimat neda, vzhledem k tomu, ze je to z principu dost staticka hra.

Jinak mas tam nejake bugy, asi trikrat z peti her se mi vubec nezobrazil ten fotbalek, slysel jsem zvuky pruzin a micku, kdyz jsem nekde klikal, ale byl videt vyber tymu nebo neco.

Jinak uz v tomhle vlakne je dost zmatek, jestli chces resit architekturu a networking a ty dalsi veci nejak dal, tak asi zaloz nova temata, tady to zapadne a nechce se mi na to uz tady nejak do detailu reagovat.

Ted uz jen hodne ve zkratce rekace na par veci (dal uz bych do tohoto vlakna tyhle veci necpal):
- dedicated server je pro tuhle hru uplne spatne, RAM je draha a je strasne neekonomicke hostovat hry dvou hracu v Unity instancich. Nehlede na dalsi problemy (reseni hostingu, spawnovani instanci, DoS)
- P2P s NAT traversalem by byl idealni
- je mi jasne, ze mi neuveris, ale resit cheatovani je nesmysl
- klidne bych na tuhle hru pouzil Photon Cloud misto UNET
- na serveru se obecne neinterpoluje
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Spytihněv



Založen: 05. 04. 2011
Příspěvky: 455
Bydliště: Praha

PříspěvekZaslal: 10. květen 2017, 09:17:27    Předmět: Odpovědět s citátem

- Opravdu je to dost nudné, ale to je prostě tím, že tenhle fotbálek je nudný i v reálu... vlastně je to v reálu jen hračka pro děti a ne seriósní hra Smile A i jako děti jsme u toho nikdy dlouho nevydrželi právě pro tu tahovost a malé možnosti jak hru ovlivnit (k míčku se dostanu jen když se ke mně skutálí atd.)

- Brankář by měl být posouvatelný pákou, aby se s ním dalo "chytat"

- Pravé tlačítko dá míček libovolnému hráči (předpokládám, že je to nějaká testovací funkce)

- Hned po spuštění vyskočí okno Windows Defenderu, že právě ochránil můj počítač, pak vyskočí další okno firewallu, že se musí povolit komunikace (nic z toho nedělá dobrý dojem)

- 14 FPS na ultra a 60 FPS na low (na low je to ošklivé, hlavně rozmazaná podlaha)

- Uživatelské rozhraní taky nic moc

- Celkově bych si za to o peníze vůbec neříkal Smile


Naposledy upravil Spytihněv dne 10. květen 2017, 12:53:58, celkově upraveno 4 krát
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Hry pro PC, konzole, ... Časy uváděny v GMT + 1 hodina
Jdi na stránku Předchozí  1, 2, 3, 4, 5  Další
Strana 3 z 5

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna