CYBERWOLF: Dobry :)
Mozna bys tam mohl nastavit konkretni procenta poskozeni, ktera vedou k vyrazeni z boje. Treba ze tank vydrzi 80%, ale vojak jen 40%.
Jeste mi neni uplne jasna ta vzdalenost. Chapu, ze je pro kazdou jednotku idealni urcita vzdalenost, ale je to vzdycky pri utoku na ruzne cile? Nemuze si tank rict, ze by radsi odstreloval vojaky na tech horach z dalky, protoze zblizka je to sice pro nej lepsi, ale vojaci budou mit urcite navrch?
Taky bych udelala mobilni lekarnicky a opravovala tanky/vojaky za provozu a tim je vracela zpet do bitvy :)

Dovolil bych si vám nabídnout takovou menší ochutnávku z koncepce systému bojů. Dá se říct, že koncepci mám už delší dobu a ořezávám z ní zbytečnosti a zjednodušuji. Současně ale chci zachovat jistou komplexnost a prostor pro hlubší strategie než jen to, kdo dokáže postavit víc jednotek. Proto pracuji s řadou různých vlastností ovlivňujících kvalitu té které jednotky v závislosti na situaci a kvalitách protivníka.

Nejprve bych ujasnil pojmy.
Útok: Přesnost, rozptyl, navádění, obratnost, zkrátka cokoliv, co ovlivňuje šanci na to protivníka útokem vůbec zasáhnout, případně zasáhnout nějakou tu Achilovu patu.
Škody: Hrubá ničivá síla útoku.

obě tyto vlastnosti jsou určeny pro 4 vzdálenosti, na které může boj probíhat (kontakt, krátká, střední, dlouhá) a každé jednotce bude víc vyhovovat jiná vzdálenost.

Obrana: opak Útoku, takže určuje, jak těžké je jednotku vůbec zasáhnout. Zahrnuje tedy velikost, pohyblivost, maskování atd.
Pancíř: obecně odolnost proti škodám. Snižuje ničivou sílu zásahu.
Výdrž: celková výdrž jednotky, jinými slovy, jak velké škody (které projdou pancířem) dokáže přežít.
Rychlost: Jak jsem zmínil u útoku a škod, tak boj může probíhat na 4 různé vzdálenosti a každé jednotce může vyhovovat jiná zvdálenost. No a rychlejší jednotka si dokáže udržet odstup, nebo se přiblížit k pomalejší. Čím větší je rozdíl rychlosti, tím rychleji se přiblíží a tím méně dostane zabrat na delší vzdálenosti (zejména pro kontaktní bojovníky je tedy rychlost velmi důležitá)

Tyto vlastnosti jsou reprezentovány celočíselnými hodnotami (čím vyšší číslo, tím lepší). V boji se berou v úvahu další faktory, jako druh jednotky, terén, taktika a podobně (například pěchota s defensivní taktikou na tom bude v horách lépe, než agresivní tank), které nějakým způsobem ovlivní zmíněné vlastnostni, není celkem podstatné jak, výsledkem je zas jen číslo (o něco vyšší nebo nižší). Následuje samotný výpočet:

Obě strany srovnají svůj útok a obranu (útok/obrana) a výsledkem je modifikátor škod, který ale nesmí být větší, než 2. Tímto modifikátorem se vynásobí škody.
Modifikované škody se potom vynásobí počtem jednotek ve skupině a odečte se od nich Pancíř cíle X počet útočících jednotek (protože pancíř tlumí každý útok zvlášť). Výsledek se ještě vydělí odmocninou Pancíře a tím získáme skutečně způsobené škody.
Pokud jsou škody vyšší, než počet cílů X jejich výdrž, tak je cílová jednotka kompletně zničena. Pokud jsou nižší, tak je zničena jen část, část může být poškozena/zraněna a část může přežít bez újmy. Přesný mechanismus rozhodování, kolik bude kterých bude, zatím nemám, ale mělo by to být do jisté míry náhodné.
Poškozené jednotky nepokračují v boji (pouze mohou utřit další škody a nechat se zabít), ale po boji mohou být opraveny/ošetřeny. K poškození ale stačí škody alespoň za polovinu výdrže, takže poškozením je možné vyřadit až dvojnásobek jednotek, než kdyby byly rovnou ničeny.

Příklad:

hodnota	útočník	obránce
Útok	1/4/6/8	5/6/5/1
Škody	2/15/15/12	12/10/8/0
Obrana	6	7
Pancíř	5	4
Výdrž	6	7
Rychlost	5	15
Počet	10	16

útočník zahájí útok na dlouhou vzdálenost (4. údaj). Obránce přejde do protiútoku a vrhne se k útočníkovi, protože preferuje kontaktní vzdálenost (1. údaj). Může si to dovolit, protože je 3x rychlejší než útočník, přesto ale cesta chvíli trvá a překonání jedné vzdálenosti (třeba z dlouhé na střední) trvá 1/3 času (rychlost protivníka/moje rychlost). Znamená to, že 1/3 kola proběhne na dlouhou, 1/3 na střední a 1/3 na krátkou vzdálenost (na kontakt to bohužel nestihnou).

Takže způsobené škody se vypočtou:
((útok/obrana)*škody)/3 pro každou ze 3 dosažených vzdáleností.
útočník: ((8/7)*12)/3 + ((6/7)*15)/3 + ((4/7)*15)/3 = 11.714285714286
obránce: ((1/6)*0)/3 + ((5/6)*8)/3 + ((6/6)*10)/3 = 5.5555555555556

teď se škody ztlumí o pancíř
útočník způsobí: ((11.714285714286 - 4) * 10) / 4 = 19.285714285715
obránce způsobí: ((5.5555555555556 - 5) * 16) / 5 = 1.7777777777779

Nakonec tedy obránci nezpůsobí skoro žádné škody a nejvýš zraní jednoho útočníka (škody jsou menší, než výdrž). Útočník oproti tomu způsobil docela slušné škody a vyřadil 3-7 obránců (v závislosti na poměru raněných a padlých). Řekněme, že obránce nezpůsobil žádné ztráty a útočník způsobil 6 zranění. Počet bojeschopných jednotek je tedy na obou stranach 10.

Tím kolo boje končí akce útočníka provede se boj další skupiny (tedy obránce). Řekněme, že obránce z minulého kola nyní útočí na útočníka a v podstatě si tak vymění role (budeme ale stále říkat minulému útočníkovi útočník a obránci obránce).

Obránce se už přiblížil na krátkou vzdálenost, ale preferuje kontakt, takže se bude přibližovat dál. Přiblížení mu zabere 1/3 času, takže 1/3 boje proběhne na krátkou vzdálenost, zbytek na kontakt.

((útok/obrana)*škody)/3 + (((útok/obrana)*škody)/3) * 2
útočník: ((4/7)*15)/3 + (((1/7)*2)/3) * 2 = 3.047619047619
obránce: ((6/6)*10)/3 + (((5/6)*12)/3) * 2 = 10

teď se škody ztlumí o pancíř
útočník způsobí: ((3.047619047619 - 4) * 10) / 4 = 0
obránce způsobí: ((10 - 5) * 10) / 5 = 10

tentokrát útočník nezpůsobil vůbec žádné škody, oproti tomu obránce vyřadil 1-3 útočníky. Jelikož útočník není dost rychlý, aby změnil vzdálenost, tak pokud bude boj takto pokračovat nemá žádnou šanci.

Je to dostatečně srozumitelné? A je to dobré? :)

CYBERWOLF: snad

TOMAS3333: spis nezaplatili hosting, treba se to jeste vrati

tak http://community.bbgamezone.com/index.php vyzera, ze je dead :/

Vzpominate, jak jsem na prelomu roku rikal, jak na te sve hre ted opravdu makam. No, uz ponekud umdlevam, presto se jeste nedostavam k bodu mrazu.

Nicmene, v lednu jsem si udelal jakysi plan na 1/4 roku do predu. I kdyz jsem vetsinu z tech veci skutecne zacal delat, tak zruba 1/3 povazuji za dotazenou do pouzitelne miry. Na druhou stranu jsem vyhazel i par kostlivcu ze skrine (a na jejich misto dosadil nove, ale alespon se tam tak nehromadi).

V konecnem dusledku tedy v planu na dalsiho 1/4 roku mam zhruba to same, co do ted, jen v jinych souvislostech, plus par veci navic. Pokud to takhle pujde dal tak termin spusteni alfaverze (9.9.09) neni zcela nerealny, ale posleni penize bych na nej taky nesazel :) (je treba vzit v uvahu i nepriznive vlivy jako jaro = alergie jako prase, ponekud vyssi nasazeni v praci a dalsi)

To jen tak pro informaci...

Na prvni pohled celkem zajimave vypadajici hra z prostredi 2.svetove valky

http://www.berlingame.cz/

CYBERWOLF: z vlastni zkusenost hrani horrovych her bych doporucoval tu vaznost, ale hlavne nevedomost, nejistotu

Resim ted takovou netechnickou otazku a to, jak to pojmout po strance pozadi, atmosfery a tak vubec. Bude se jednat o sci-fi horror (tj. neco jako treba Doom), coz by na jednu stranu chtelo pristupovat k tomu dost vazne, aby to pusobilo desive. Na druhou stranu, zejmena hororove rekvizity jsou dost pitomosti a tvarit se na ne smrtelne vazne je k smichu samo o sobe. Pokud k tomu budu pristupovat s humorem, tak pak tam z toho hororu zustanou akorat ty rekvizity.

Co myslite, je lepsi tvarit se vazne, nebo si z toho spis delat srandu?

To je pak otazka co vlastne ta hra bude muset okamzite propocitat. U me je to spis simulator, protoze kazdy clovicek (radek v db) bude mit vlastni jmeno. Z toho pak vyplyva i chovani, individualni vlastnosti kazdeho clovicka a tak dale. Pokud ale v kazdem tahu kontrolujes jestli se neco dostavelo, tak asi neni moc co resit :)

Delam sms souteze a hrani si s rychlosti nejakeho dotazu obcas znamena, ze vylosuji par tisic vyhercu za 5 minut misto 2 hodin :D A to ted nemluvim jen o indexech :)

Tak bez indexu to nejde, to je jasny:) Z vlastni zkusenosti vim, ze i MySQL zvlada tabulky s par miliony zaznamu docela rychle (samozrejme se nesmi tahat cela tabulka, ale to uz se pak prenasi celkem dost MB a to urcite sezere dost prostredku s kazdou databazi).

No, shrnul bych to asi tak:
V soucasne dobe resim pres objekty skoro vsechno, s optimalizaci si lamu hlavu pouze pokud mi prijde, ze neco jde moc pomalu (ne ze bych to schvalne delal neoptimalizovane, proste si nelamu hlavu s kazdou milisekundou) a tudiz mam v tomto smeru slusne rezervy, kdyz neco zkousim, tak si vytvorim docela slusny balik dat na databazi a na mem desktopu s WinXP se drtiva vetsina vsech akci provede do 0.050 sec. Weby na Zend Frameworku, na kterych se bezne pohybuji stovky az tisice lidi soucasne mi generguji stranku zhruba 4-5x tak dlouho. I kdyz predpokladam, ze tito navstevnici nebudou klikat tak casto jako uzivatele me hry a nebudu toho mit tolik, co by se dalo nacachovat, porad si myslim, ze by i bez jakekoliv dalsi optimalizace do tisice hracu nemel byt problem.

Jinak s pristupem, kdy se setri kazdy bajt a milisekunda a tudiz je vse bud prosty php kod nebo maximalne funkce atd. jsem uz parkrat pohorel. Ted to zkousim takhle a zatim jsem se dostal dal, nez kdy predtim. Az budu mit funkcni hru a problem s vykonem, tak se k tomuto pristupu treba vratim, ale do te doby budu pokracovat v nastolenem trendu:)

CYBERWOLF: z casti uz to tu probehlo, ale stejne to napisu

cim vic logiky das do db tim lepe, uz jen protoze neresis zpozdeni na presunu dat php-db-php-db-php-db .... ale je to php-dblogika-dbdata-dblogika-php

pokud musis zustat u mysql (nad 60k zaznamu v tabulce hrozne zpomaluje a pak resis UNIONy, s logikou tam toho moc neudekas) tak jedine cim budes moci ladit rychlost jsou indexy nad tabulkama (je pravda ze tam toho jde udelat hodne, z vlastni zkusenosti spojenim 3 indexu do jednoho zkraceni z 45sec na 3sec)

php je pomale, ale pokud pouzivas objekty, je extremne pomale; objekty jsou v php silena nadstavba ... kterou pridali, aby byly vice cool, jenze uz z povahy jazyka (interpretovany) je to silena konina hlavne pri zahazovani veskere prace ihned po zobrazeni stranky

pokud nejvic casu zabiraji operace s textem/cisly zkus se zamyslet nad perlovy scriptiky, ktery bys z php volal, posun v rychlosti by byl dost extremni

Jednoduse, vytvoris si pole, das do nej data ohledne prostupnosti a pak budes resit obtekani a nejkratsi cestu. Na poledniky bych (osobne) nebrala ohled :)

Osobne delam v postgresu a nevim jak jsou veci resene v mysql (s tim jsem skoncila kdysi hodne davno), ale psani a udrzovani je naprosto prehledne. Proste mam vsechny fce napsane v textacich a kdyz chci neco zmenit, tak proste napisu v prikazove radce, aby mi textak nalil do databaze.

Napr. ja tam mam pohyb reprezentovany mapou sveta, rozdelenou do sektoru, ktere odpovidaji zemepisne delce a sirce. Pokud chci cestovat z bodu A do bodu B, tak vypocitam trasu, zjistim, jestli se danou trasou da projit (treba ze tam zrovna neni more) a jak dlouho bude cesta trvat (poledniky se se vzdalenosti od rovniku vzajeme priblizuji). Byl docela masakr tohle udelat i v php, jak bych to delal na urovni SQL, to si neumim predstavit...

PHP je pomale, protoze se pri kazdem spusteni kod nejdrive zkontroluje, zkompiluje a pak teprve pusti. Ovsem s pouzitm napr. eAcceleratoru prvni dva kroky odpadaji :)

Nevim, jak jsou na tom jine databazove systemy, ale s MySQL muzu jen tezko vytvorit celou logiku na databazove urovni tak, aby se s tim dalo rozume pracovat a tady je holt treba se rozhodnout, jestli radsi obetovat rychlost nebo prehlednost a udrzovatelnost.

No a pokud se neukaze, ze neco vyslovene nejde, protoze je to pomaly, tak uprednostnuji prehlednost a udrzovatelnost:)

PHP je hrozne pomale, osobne ho pouzivam jen na osetreni vstupu a na vystup sablon.
Mit celou logiku uvnitr db je jednoznacne plus.


CYBERWOLF: Vzhledem k tomu, ze budu mit 3x delsi tahy nez ty, tech objektu tam vic jak 100k nebude a stroj, na kterem jsem to merila byla pouze pomala p3, tak se toho nebojim :)
A i kdyby se to stalo, tak od toho jsou pak priority. Nektere veci se proste vykonat nemusi.

Jinak optimalizaci bych resila uz na zacatku. Uvedu konkretni priklad. Mam 100 000 clovicku (cti radku v db) a kazdy z nich starne, tzn. kazdy tah je update. Update byl radove 30-60s (IIRC, mozna vic). Tak jsem to udelala tak, ze se nastavi pouze tah narozeni clovicka a dal se vek pocita jako aktualni tah-tah narozeni. Zadny update, zadny insert a kontrola starnuti byla za 200ms hotova :) A s takovou veci musis pocitat uz od zacatku, jinak to budes muset zpetne prepracovat a to neni zrovna zabavne :)

MICTECH: Tak tohle jsou veci, co se vzajeme nevylucuji:) Dotazy pisu rucne, ale prohanim skrz knihovnu (dibi) a pokud prijdu na pripad, kdy to bude vyhodne, budu resit ulozene procedury.

CYBERWOLF: tohle neni moc o optimalizaci, tohle by jsi mel resit pri navrhu, jakym zpusobem bude resena DB vrstva

jestli si budes psat vsechny SQL rucne, pouzijes nejakou DB knihovnu v php nebo treba budes pouzivat mnou zmineny procedury a jen je volat s danyma parametrama

No, zatim bych to s tou optimalizaci moc neprehanel. Je tam toho jeste dost, co by se dalo poladit a ted to bezi pomerne snesitelne, takze jeste je kde to zrychlit a predcasna optimalizace je zdrojem vseho zla:)

WEWERKA: Tak z toho, co tu pises, bych mel docela hruzu:) Nekonecny cyklus, ktery si to dela jak mu to zrovna jde... Co kdyz toho bude proste moc a pretece to do dalsiho tahu?

CYBERWOLF: pokud chces usetrit komunikaci mezi php a db, tak to udelej pres storovane procedury