Table Football Pro - na Greenlightu

[Ladis]

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" . 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.

[Diskobolos]

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 ...
Pokud odladím tu síť, jdu do toho.
Určitě vám sem dám build na vyzkoušení.

[Diskobolos]

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á!

[Radis]

[Diskobolos]

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?

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í.

[Diskobolos]

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!

[Diskobolos]

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?

[Radis]

[Diskobolos]

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

[Diskobolos]

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.).

[Diskobolos]

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.

[Ladis]

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ší...

[Diskobolos]

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.

[Radis]

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

[Spytihněv]

- 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 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